# Выполнение работ по созданию, развитию и вводу в эксплуатацию цифровой экосистемы Федерального государственного бюджетного учреждения культуры «Государственный центральный театральный музей имени А. А. Бахрушина»

- Номер: 0373100047526000034 (44-ФЗ)
- Заказчик: ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ КУЛЬТУРЫ "ГОСУДАРСТВЕННЫЙ ЦЕНТРАЛЬНЫЙ ТЕАТРАЛЬНЫЙ МУЗЕЙ ИМЕНИ А.А. БАХРУШИНА"
- НМЦК: 71 500 000,00 ₽
- Подача заявок до: 26.10.2026
- Карточка ЕИС: https://zakupki.gov.ru/epz/order/notice/ok20/view/common-info.html?regNumber=0373100047526000034

**Требование к опыту:** Опыт обязателен (3 г.) — Карточка ЕИС (ч. 2.1 ст. 31 44-ФЗ, ПП № 2571): исполненный контракт/договор за 3 года на сумму не менее 20% НМЦК без неоплаченных неустоек
**Суть:** Создать цифровую экосистему Театрального музея им. Бахрушина на 1С-Битрикс/Битрикс24: новый основной сайт по имеющемуся макету, перенос сайта Фонда, редизайн интернет-магазина и Flutter-приложения, единый вход и личный кабинет, CRM, программа лояльности, игровые механики с AR, квестами и викторинами, аналитика, интеграции с билетной системой, 1С и КАМИС. Четыре этапа: запуск сайта и магазина к 20.12.2026, затем до 31.05.2027 и 01.11.2027, после — 90 дней стабилизации.
**Тип проекта:** Новое + поддержка
**Сроки:** этап 1 — с заключения до 20.12.2026; этап 2 — до 31.05.2027; этап 3 — до 01.11.2027; этап 4 — 90 дней после приёмки этапа 3
**Оплата:** аванс 30% цены каждого этапа (казначейское сопровождение); остаток — по факту приёмки этапа за вычетом аванса
**Гарантия:** 6 месяцев с приёмки этапа 3 (стабилизация входит в гарантию); обеспечение гарантии не требуется
**Права на результат:** исключительные права на результаты, исходный код и документацию переходят музею, вознаграждение входит в цену
**Только СМП/СОНКО:** нет
**Очное присутствие:** Неясно
**Про присутствие:** место работ: «по месту нахождения Подрядчика, на объектах и в информационной инфраструктуре Заказчика, а также дистанционно»; демонстрации, обучение и пилотное наполнение AR и квестов по музею вероятно требуют присутствия в Москве
**Можно ли сразу:** С условиями
**Пояснение:** проект во многом новый, но нужна сильная команда на Битрикс и Flutter, готовность принять чужой код без документации, обеспечение 30% цены (~21 млн руб.) и запуск сайта и магазина за 4–5 недель после подписания
**Существующая система:** интернет-магазин на 1С-Битрикс24, мобильное приложение на Flutter с серверной частью, сайт Фонда, билетная система HighWay Media, КАМИС «Коллекция онлайн», 1С, CRM; исходный код передаётся без репозиториев, инструкций сборки и схем БД
**Как выбирают:** открытый конкурс: цена 30%, качество предложений 60% (5 показателей по 20%: мобильное приложение и AR, билетный контур и квесты, викторины, макет главной; оценка 0 или 100), квалификация 10% (число договоров)
**Сложность:** high
**Комментарий:** очень крупный проект (71,5 млн руб.) с обеспечением 30% — небольшой студии только в субподряде

## Признаки заточки под исполнителя: 15% (низкий)
Найден один признак — нереалистичный срок первого этапа: свой же план ТЗ отводит на веб-контур до 120 дней, а этап 1 надо закрыть к 20.12.2026. У заказчика уже есть утверждённый макет основного сайта, то есть кто-то делал дизайн заранее. Остальное не похоже на заточку: Битрикс обусловлен работающим магазином, опыт оценивается широко и весит 10%, хотя оценка предложений «0 или 100» за 60% веса субъективна.
- exec_too_short (+15): «С даты заключения контракта до 20.12.2026» — Подача до 26.10, контракт около середины ноября — на этап 1 остаётся 4–5 недель: обследование систем, архитектура, новый основной сайт с CMS и билетным контуром, редизайн интернет-магазина, нагрузочные проверки и обучение. По собственному календарному плану ТЗ веб-контур занимает 30–120-й день — участник прямо спросил о противоречии. ≈4–6 человеко-месяцев за месяц: возможно только большой командой или тем, у кого заготовки уже есть. [docs/0373100047526000034/Приложение № 1 к извещению Техническое_задание_на_цифровую_экосистему_Музея_23_09_2026 (1).pdf]
Возможные честные причины: Музей хочет показать результат в этом бюджетном году и запустить сайт к декабрю. Бюджет 2026 года нужно освоить, поэтому первый этап сжат. Макет мог сделать прежний подрядчик или штатный дизайнер.

## Что сделать
- этап 1 (до 20.12.2026): основной сайт на русском (главная, афиша, новости, филиалы), CMS, билетный контур, редизайн интернет-магазина, базовая аналитика и инфраструктура, нагрузочные проверки
- этап 2 (до 31.05.2027): полный сайт с поиском, сайт Фонда на общей CMS, витрина коллекции из КАМИС, единый SSO и ЛК, CRM, лояльность, уведомления, RU/EN
- этап 3 (до 01.11.2027): игровые механики, квесты, викторины, AR, аудиогиды с пилотным наполнением, редизайн и доработка мобильного приложения на Flutter, аудиты ИБ и доступности (WCAG 2.2 AA), 720 часов опытной эксплуатации
- этап 4: 90 дней стабилизации с круглосуточной реакцией на критические инциденты
- дизайн-система и UI Kit в Figma, миграция данных, интеграции с HighWay Media, 1С, Битрикс24, платёжным провайдером, ККТ и ОФД
- передача исходников, репозиториев, CI/CD, документации и исключительных прав

## Платформа и технологии
- 1С-Битрикс
- Битрикс24
- Flutter
- КАМИС
- 1С
- HighWay Media
- Figma

## Допуски, пропуска, режим
- доступ к инфраструктуре заказчика по согласованным защищённым каналам
- обработка персональных данных посетителей, согласия, фискализация платежей
- независимые аудиты ИБ и цифровой доступности

## Лицензии и членство
- лицензии 1С-Битрикс/Битрикс24 по итогам обследования — за счёт подрядчика в цене контракта

## Штрафы и риски
- обеспечение исполнения 30% цены контракта (~21,45 млн руб. от НМЦК)
- этап 1 нереально сжат: сайт и редизайн магазина к 20.12.2026
- твёрдая цена при объёме, определяемом «полнотой ТЗ» без предельных количественных показателей
- приёмка по сквозным сценариям и 720 часам опытной эксплуатации без сбоев
- лицензии Битрикс за счёт подрядчика

_Выжимка сделана автоматически по документам закупки; юридически значимы только сами документы (файлы в папке «Документы» и текст в 01_ТЕКСТ_ВСЕХ_ДОКУМЕНТОВ.txt)._


# ПОЛНЫЙ ТЕКСТ ДОКУМЕНТОВ

=== ФАЙЛ: Приложение № 4 к извещению Требования к содержанию и составу заявки | docs/0373100047526000034/Приложение № 4 к извещению Требования к содержанию и составу заявки.pdf
Приложение № 4 к Извещению
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ, СОСТАВУ ЗАЯВКИ НА УЧАСТИЕ В
ЭЛЕКТРОННОМ КОНКУРСЕ И ИНСТРУКЦИЯ ПО ЕЕ ЗАПОЛНЕНИЮ.
1. Подать заявку на участие в закупке вправе только зарегистрированный в единой информационной системе
и аккредитованный на электронной площадке, специализированной электронной площадке участник закупки путем
направления такой заявки в соответствии с Законом №44-ФЗ оператору электронной площадки, оператору
специализированной электронной площадки.
2. Участник закупки вправе подать только одну заявку на участие в закупке в любое время с момента
размещения в единой информационной системе извещения об осуществлении закупки до окончания установленного
в соответствии с Законом №44-ФЗ срока подачи заявок на участие в закупке.
3. Подача заявки на участие в закупке означает согласие участника закупки, подавшего такую заявку, на
поставку товара, выполнение работы, оказание услуги на условиях, предусмотренных извещением об
осуществлении закупки и в соответствии с заявкой такого участника закупки на участие в закупке.
4. Во второй части заявки на участие в открытом конкурсе в электронной форме не допускается указания
информации о предложении участника закупки, предусмотренном ч. 1.3 Требования к содержанию, составу заявки
на участие в закупке в соответствии с Законом №44-ФЗ и инструкция по ее заполнению.
Требования к содержанию, составу заявки на участие в закупке в соответствии с Федеральным законом от
05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения
государственных и муниципальных нужд» (далее – Закон №44-ФЗ) и инструкция по ее заполнению.
1. В соответствии с частью 2 статьи 48 Закона №44-ФЗ заявка на участие в электронном конкурсе состоит из
трех частей.
1.1. Первая часть должна содержать:
предложение по критерию: качественные, функциональные и экологические характеристики объекта закупки.
Отсутствие такого предложения не является основанием для отклонения заявки на участие в закупке.
1.2. Вторая часть должна содержать:
1) решение о согласии на совершение или о последующем одобрении крупной сделки, если требование о
наличии такого решения установлено законодательством Российской Федерации, учредительными документами
юридического лица и для участника закупки заключение контракта на поставку товара, выполнение работы или
оказание услуги, являющихся объектом закупки, либо внесение денежных средств в качестве обеспечения заявки на
участие в закупке, обеспечения исполнения контракта является крупной сделкой;
2) документы, подтверждающие соответствие участника закупки дополнительным требованиям,
установленным в соответствии с частью 2.1 статьи 31 Закона №44-ФЗ, а именно:
- исполненный участником закупки (с учетом правопреемства) в течение трех лет до даты подачи заявки на
участие в закупке контракт или договор, заключенный в соответствии с Федеральным законом от 18 июля 2011 года
N 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» при условии исполнения таким
участником закупки требований об уплате неустоек (штрафов, пеней), предъявленных при исполнении таких
контракта, договора. Стоимость исполненных обязательств по таким контракту, договору должна составлять не
менее двадцати процентов начальной (максимальной) цены контракта.
Информацией и документами, подтверждающими соответствие участника закупки дополнительному
требованию, установленному в соответствии с частью 2.1 статьи 31 Закона №44-ФЗ, являются:
а) номер реестровой записи в предусмотренном Законом №44-ФЗ реестре контрактов, заключенных
заказчиками (в случае исполнения участником закупки контракта, информация и документы в отношении которого
включены в установленном порядке в такой реестр и размещены на официальном сайте единой информационной
системы в информационно-телекоммуникационной сети «Интернет»);
б) выписка из предусмотренного Законом №44-ФЗ реестра контрактов, содержащего сведения, составляющие
государственную тайну (в случае исполнения участником закупки контракта, информация о котором включена в
установленном порядке в такой реестр);
в) исполненный контракт, заключенный в соответствии с Законом №44-ФЗ, или договор, заключенный в
соответствии с Федеральным законом «О закупках товаров, работ, услуг отдельными видами юридических лиц», а
также акт приемки поставленных товаров, выполненных работ, оказанных услуг, подтверждающий цену
поставленных товаров, выполненных работ, оказанных услуг.
3) декларацию о соответствии участника закупки требованиям, установленным пунктами 3 - 5, 7 - 11 части 1
статьи 31 Закона №44-ФЗ:
3. непроведение ликвидации участника закупки - юридического лица и отсутствие решения арбитражного
суда о признании участника закупки - юридического лица или индивидуального предпринимателя несостоятельным
(банкротом) и об открытии конкурсного производства;
4. неприостановление деятельности участника закупки в порядке, установленном Кодексом Российской
Федерации об административных правонарушениях;
5. отсутствие у участника закупки недоимки по налогам, сборам, задолженности по иным обязательным
платежам в бюджеты бюджетной системы Российской Федерации (за исключением сумм, на которые предоставлены
отсрочка, рассрочка, инвестиционный налоговый кредит в соответствии с законодательством Российской Федерации
о налогах и сборах, которые реструктурированы в соответствии с законодательством Российской Федерации, по
которым имеется вступившее в законную силу решение суда о признании обязанности заявителя по уплате этих
сумм исполненной или которые признаны безнадежными к взысканию в соответствии с законодательством
Российской Федерации о налогах и сборах) за прошедший календарный год, размер которых превышает двадцать
пять процентов балансовой стоимости активов участника закупки, по данным бухгалтерской отчетности за
последний отчетный период. Участник закупки считается соответствующим установленному требованию в случае,
если им в установленном порядке подано заявление об обжаловании указанных недоимки, задолженности и решение
по такому заявлению на дату рассмотрения заявки на участие в определении поставщика (подрядчика, исполнителя)
не принято;
7. отсутствие у участника закупки - физического лица либо у руководителя, членов коллегиального
исполнительного органа, лица, исполняющего функции единоличного исполнительного органа, или главного
бухгалтера юридического лица - участника закупки судимости за преступления в сфере экономики и (или)
преступления, предусмотренные статьями 289, 290, 291, 291.1 Уголовного кодекса Российской Федерации (за
исключением лиц, у которых такая судимость погашена или снята), а также неприменение в отношении указанных
физических лиц наказания в виде лишения права занимать определенные должности или заниматься определенной
деятельностью, которые связаны с поставкой товара, выполнением работы, оказанием услуги, являющихся объектом
осуществляемой закупки, и административного наказания в виде дисквалификации;
7.1 участник закупки - юридическое лицо, которое в течение двух лет до момента подачи заявки на участие в
закупке не было привлечено к административной ответственности за совершение административного
правонарушения, предусмотренного статьей 19.28 Кодекса Российской Федерации об административных
правонарушениях;
8. обладание участником закупки исключительными правами на результаты интеллектуальной деятельности,
если в связи с исполнением контракта заказчик приобретает права на такие результаты, за исключением случаев
заключения контрактов на создание произведений литературы или искусства, исполнения, на финансирование
проката или показа национального фильма;
9. отсутствие обстоятельств, при которых должностное лицо заказчика (руководитель заказчика, член
комиссии по осуществлению закупок, руководитель контрактной службы заказчика, контрактный управляющий),
его супруг (супруга), близкий родственник по прямой восходящей или нисходящей линии (отец, мать, дедушка,
бабушка, сын, дочь, внук, внучка), полнородный или неполнородный (имеющий общих с должностным лицом
заказчика отца или мать) брат (сестра), лицо, усыновленное должностным лицом заказчика, либо усыновитель этого
должностного лица заказчика является:
а) физическим лицом (в том числе зарегистрированным в качестве индивидуального предпринимателя),
являющимся участником закупки;
б) руководителем, единоличным исполнительным органом, членом коллегиального исполнительного органа,
учредителем, членом коллегиального органа унитарной организации, являющейся участником закупки;
в) единоличным исполнительным органом, членом коллегиального исполнительного органа, членом
коллегиального органа управления, выгодоприобретателем корпоративного юридического лица, являющегося
участником закупки. Выгодоприобретателем для целей настоящей статьи является физическое лицо, которое
владеет напрямую или косвенно (через юридическое лицо или через несколько юридических лиц) более чем десятью
процентами голосующих акций хозяйственного общества либо владеет напрямую или косвенно (через юридическое
лицо или через несколько юридических лиц) долей, превышающей десять процентов в уставном (складочном)
капитале хозяйственного товарищества или общества;
10. участник закупки не является офшорной компанией, не имеет в составе участников (членов)
корпоративного юридического лица или в составе учредителей унитарного юридического лица офшорной компании,
а также не имеет офшорных компаний в числе лиц, владеющих напрямую или косвенно (через юридическое лицо
или через несколько юридических лиц) более чем десятью процентами голосующих акций хозяйственного общества
либо долей, превышающей десять процентов в уставном (складочном) капитале хозяйственного товарищества или
общества;
10.1 участник закупки не является иностранным агентом;
11. отсутствие у участника закупки ограничений для участия в закупках, установленных законодательством
Российской Федерации.
4) реквизиты счета участника закупки, на который в соответствии с законодательством Российской
Федерации осуществляется перечисление денежных средств в качестве оплаты поставленного товара, выполненной
работы (ее результатов), оказанной услуги, а также отдельных этапов исполнения контракта, за исключением
случаев, если в соответствии с законодательством Российской Федерации такой счет открывается после заключения
контракта.
1.3. Третья часть должна содержать:
предложение участника закупки о цене контракта.
2. Заявка участника должна содержать:
а) полное и сокращенное (при наличии) наименование юридического лица, в том числе иностранного
юридического лица (если участником закупки является юридическое лицо), аккредитованного филиала или
представительства иностранного юридического лица (если от имени иностранного юридического лица выступает
аккредитованный филиал или представительство), наименование обособленного подразделения юридического лица
(если от имени участника закупки выступает обособленное подразделение юридического лица), фамилия, имя,
отчество (при наличии) (если участником закупки является физическое лицо, в том числе зарегистрированное в
качестве индивидуального предпринимателя);
б) фамилию, имя, отчество (при наличии), идентификационный номер налогоплательщика (при наличии) и
должность лица, имеющего право без доверенности действовать от имени юридического лица, либо действующего в
качестве руководителя юридического лица, аккредитованного филиала или представительства иностранного
юридического лица, либо исполняющего функции единоличного исполнительного органа юридического лица;
в) идентификационный номер налогоплательщика (при наличии) членов коллегиального исполнительного
органа, лица, исполняющего функции единоличного исполнительного органа, управляющего (при наличии),
управляющей организации (при наличии), участников (членов) корпоративного юридического лица, владеющих
более чем двадцатью пятью процентами акций (долей, паев) корпоративного юридического лица, учредителей
унитарного юридического лица или в соответствии с законодательством соответствующего иностранного
государства аналог идентификационного номера налогоплательщика таких лиц;
г) адрес юридического лица, в том числе иностранного юридического лица (если участником закупки является
юридическое лицо) в пределах места нахождения юридического лица, адрес (место нахождения) аккредитованного
филиала или представительства на территории Российской Федерации (если от имени иностранного юридического
лица выступает аккредитованный филиал или представительство), адрес (место нахождения) обособленного
подразделения юридического лица (если от имени участника закупки выступает обособленное подразделение
юридического лица), место жительства физического лица, в том числе зарегистрированного в качестве
индивидуального предпринимателя (если участник закупки является физическим лицом, в том числе
зарегистрированным в качестве индивидуального предпринимателя), адрес электронной почты, номер контактного
телефона;
д) копию документа, удостоверяющего личность участника закупки в соответствии с законодательством
Российской Федерации (если участник закупки является физическим лицом, не являющимся индивидуальным
предпринимателем);
е) идентификационный номер налогоплательщика юридического лица (если участником закупки является
юридическое лицо), аккредитованного филиала или представительства иностранного юридического лица (если от
имени иностранного юридического лица выступает аккредитованный филиал или представительство), физического
лица, в том числе зарегистрированного в качестве индивидуального предпринимателя (если участником закупки
является физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя), аналог
идентификационного номера налогоплательщика в соответствии с законодательством соответствующего
иностранного государства (если участником закупки является иностранное лицо), код причины постановки на учет
юридического лица (если участником закупки является юридическое лицо), аккредитованного филиала или
представительства иностранного юридического лица (если от имени иностранного юридического лица выступает
аккредитованный филиал или представительство), обособленного подразделения юридического лица (если от имени
участника закупки выступает обособленное подразделение юридического лица);
ж) выписку из единого государственного реестра юридических лиц (если участником закупки является
юридическое лицо), выписка из единого государственного реестра индивидуальных предпринимателей (если
участником закупки является индивидуальный предприниматель);
з) надлежащим образом заверенный перевод на русский язык документов о государственной регистрации
юридического лица или физического лица в качестве индивидуального предпринимателя в соответствии с
законодательством соответствующего государства (если участником закупки является иностранное лицо);
и) декларацию о принадлежности участника закупки к учреждению или предприятию уголовноисполнительной системы (если участник закупки является учреждением или предприятием уголовноисполнительной системы) (предоставляется в случае установления преимуществ в извещении об осуществлении
закупки).
к) декларацию о принадлежности участника закупки к организации инвалидов, предусмотренной частью 2
статьи 29 Закона №44-ФЗ (если участник закупки является такой организацией) (предоставляется в случае
установления преимуществ в извещении об осуществлении закупки).
л) декларацию о принадлежности участника закупки к социально ориентированным некоммерческим
организациям в случае установления преимущества, предусмотренного частью 3 статьи 30 Закона №44-ФЗ
(предоставляется в случае установления преимуществ в извещении об осуществлении закупки).
Примечание:
Информация и документы, предусмотренные пунктами «а» - «л» части 2 Требования к содержанию, составу
заявки на участие в закупке в соответствии с Законом №44-ФЗ и инструкция по ее заполнению, не включаются
участником закупки в заявку на участие в закупке. Такие информация и документы в случаях, предусмотренных
Законом №44-ФЗ, направляются (по состоянию на дату и время их направления) заказчику оператором
электронной площадки, оператором специализированной электронной площадки путем информационного
взаимодействия с единой информационной системой.
Рекомендуемая форма № 1
Наличие у участников закупки опыта работы, связанного с предметом контракта
№№
п/п
Предмет
Контракта(Договора)
Заказчик
Стоимость
контракта/договор
а, руб.
Номер и дата
контракта/договора
Номер извещения
в ЕИС*
Сведения о
контракте/договоре, на
основании которого
заключен договор суб.
подряда, суб исполнителя
(номер, дата, номер
извещения в ЕИС) **
№ и дата Акта приемки
выполненных работ
1
2
3
4
5
6
7
8
ИТОГО:
«Указать общую стоимость контрактов/договоров, руб.
Заполняется в случае представления контрактов/договоров, заключенных в рамках Закона 44-ФЗ или 223-ФЗ. Данные таких контрактов сравниваются также с их данными, размещенными ЕИС.
* Заполняется в случае представления договоров субподряда(соисполнителя).

=== ФАЙЛ: Приложение № 5 к извещению Порядок оценки заявок | docs/0373100047526000034/Приложение № 5 к извещению Порядок оценки заявок.pdf
ПОРЯДОК
рассмотрения и оценки заявок на участие в конкурсе
I.
Информация о заказчике и закупке товаров, работ, услуг для обеспечения
государственных и муниципальных нужд (далее – закупка)
Коды
Полное наименование:
Юридический адрес,
телефон, адрес
электронной почты:
Наименование объекта
закупки
Федеральное государственное бюджетное учреждение культуры
«Государственный центральный театральный музей им. А. А.
Бахрушина» (Театральный музей им. А.А. Бахрушина)
115054, Москва, ул. Бахрушина, 31/12, стр.1.
тел: +7 (499) 484-77-77
e-mail: mail@bakhrushinmuseum.ru
Выполнение работ по созданию, развитию и вводу в эксплуатацию
цифровой экосистемы Федерального государственного бюджетного
учреждения культуры «Государственный центральный театральный
музей имени А. А. Бахрушина».
ИНН
7705042669
КПП
770501001
по
ОКТМО
45376000
II.
№
1
Критерии и показатели оценки заявок на участие в электронном конкурсе
Крите
рий оценки
1 Цена
контракта,
сумма
цен
единиц
товара,
работы,
услуги
Зн
ачимость
критерия
оценки,
проценто
в
30
Пока
затель
оценки
-
Зн
ачимость
показател
я оценки,
проценто
в
-
Показатель
оценки,
детализирующий
показатель оценки
-
Значимость
показателя,
детализирующего
показатель оценки,
процентов
-
Формула оценки или шкала оценки
Оценка заявок осуществляется по формулам,
предусмотренным пунктами 9 и 10
Положения об оценке заявок на участие в
закупке товаров, работ, услуг для
обеспечения
государственных
и
муниципальных
нужд,
утвержденного
постановлением Правительства Российской
Федерации от 31 декабря 2021 г. №2604 «Об
оценке заявок на участие в закупке товаров,
работ,
услуг
для
обеспечения
государственных и муниципальных нужд,
внесении
изменений
в
пункт
4
постановления Правительства Российской
Федерации от 20 декабря 2021 г. №2369 и
признании утратившими силу некоторых
актов и отдельных положений некоторых
актов
Правительства
Российской
Федерации» (далее – Положение):
1.1. Значение количества баллов,
присваиваемое заявке, которая подлежит в
соответствии с Законом № 44-ФЗ оценке по
критерию оценки «Цена контракта, сумма
цен единиц товара, работы, услуги» (БЦ i)
определяется по одной из следующих
формул:
а)
за
исключением
случаев,
предусмотренных
подпунктом
«б»
настоящего пункта и пунктом 1.2, - по
формуле:
 Ц -Ц 
БЦ i =100 -  i л  ×100,
 Цл 
где:
Цi - предложение участника закупки о
цене контракта, или о сумме цен всех
контрактов, заключаемых по результатам
проведения совместного конкурса (в случае
проведения совместного конкурса), или о
сумме цен единиц товара, работы, услуги (в
случае, предусмотренном частью 24 статьи
22 Закона № 44-ФЗ, в том числе при
проведении в этом случае совместного
конкурса), заявка (часть заявки) которого
подлежит в соответствии с Законом № 44-ФЗ
оценке по критерию оценки «Цена
контракта, сумма цен единиц товара, работы,
услуги» (далее - ценовое предложение);
Цл - наилучшее ценовое предложение
из числа предложенных в соответствии с
Законом № 44-ФЗ участниками закупки,
заявки (части заявки) которых подлежат
оценке по критерию оценки «Цена
контракта, сумма цен единиц товара, работы,
услуги»;
б) в случае если по результатам
применения формулы, предусмотренной
подпунктом «а» настоящего пункта, при
оценке хотя бы одной заявки получено
значение,
являющееся
отрицательным
числом, значение количества баллов по
критерию оценки «Цена контракта, сумма
цен единиц товара, работы, услуги» всем
заявкам, подлежащим в соответствии с
Законом № 44-ФЗ оценке по указанному
критерию оценки (БЦi), определяется по
формуле:
БЦ i = Ц нач - Ц i  
100
,
Ц нач - Ц л
где Цнач - начальная (максимальная)
цена контракта, или сумма начальных
(максимальных) цен каждого контракта,
заключаемого по результатам проведения
совместного конкурса (в случае проведения
совместного конкурса), или начальная сумма
цен единиц товаров, работ, услуг (в случае,
предусмотренном частью 24 статьи 22
Закона № 44-ФЗ, в том числе при проведении
в таком случае совместного конкурса).
1.2. Если при проведении процедуры
подачи предложений о цене контракта либо о
сумме цен единиц товара, работы, услуги (в
случае, предусмотренном частью 24 статьи
22 Закона № 44-ФЗ) в соответствии с
Законом № 44-ФЗ подано ценовое
предложение, предусматривающее снижение
таких цены контракта либо суммы цен ниже
нуля, значение количества баллов по
критерию оценки «Цена контракта, сумма
цен единиц товара, работы, услуги» (БЦi)
определяется в следующем порядке:
а) для подлежащей в соответствии с
Законом № 44-ФЗ оценке заявки участника
закупки, ценовое предложение которого не
предусматривает снижение цены контракта
либо суммы цен ниже нуля, по критерию
оценки «Цена контракта, сумма цен единиц
товара, работы, услуги» значение количества
баллов по указанному критерию оценки (БЦi)
определяется по формуле:
 Ц + Цл 
БЦ i = 100 -  i
  100;
 Ц нач + Ц л 
б) для подлежащей в соответствии с
Законом № 44-ФЗ оценке заявки участника
закупки, ценовое предложение которого
предусматривает снижение цены контракта
либо суммы цен ниже нуля, по критерию
оценки «Цена контракта, сумма цен единиц
товара, работы, услуги» значение количества
баллов по указанному критерию оценки
(БЦi) определяется по формуле:
 Ц л - Цi 
БЦ i =100 - 
 ×100.
 Ц нач + Ц л 
1.3. Оценка заявок по критерию
оценки «Цена контракта, сумма цен единиц
товара, работы, услуги» осуществляется в
соответствии со следующими требованиями:
а) заявкам, содержащим наилучшее
ценовое предложение, а также предложение,
равное такому наилучшему ценовому
предложению, присваивается 100 баллов;
б) значение Цл при применении
формулы, предусмотренной подпунктом «а»
пункта 1.2, и значения Цл и Цi при
применении формулы, предусмотренной
подпунктом «б» пункта 1.2, указываются без
знака «минус»;
в) применение показателей оценки по
критерию оценки «Цена контракта, сумма
2
Качественные
.
,
функциональ
ные и
экологически
е
характеристи
ки объекта
закупки
60
Качественны 100
е
характерист
ики объекта
закупки
Характеристика №1
Предложение
по
составу
и
содержанию
выполнения работ по
пункту
9.8.1
(Редизайн
и
доработка
мобильного
приложения)
и
подпункту
9.10.8
(Дополненная
реальность)
Технического
задания, в части
конкретных
технических решений
(демонстрирующее
понимание предмета
выполняемых работ)
20
Характеристика №2
20
Предложение
по
составу
и
содержанию
выполнения работ по
пункту
9.10.8
(Дополненная
реальность)
и
подпункту
9.10.12
(Обязательный объем
реализации)
Технического
задания, в части
цен единиц товара, работы, услуги» не
допускается.
При наличии предложений по составу и
содержанию работ заявке присваивается:
- 100 баллов – представлены все три
элемента, каждый содержит конкретные
технические решения, не является
пересказом ТЗ.
- 0 баллов – отсутствие любого из
обязательных элементов или представление
формальных отсылок к ТЗ без собственных
решений.
При наличии предложений по составу
и содержанию работ заявке присваивается:
 100 баллов – представлены все
обязательные материалы с
детализацией технологических
решений.

.
0 баллов – отсутствие блок-схем или
описания этапов работ.
конкретных
технических решений
(демонстрирующее
понимание предмета
выполняемых работ)
Характеристика №3
20
Предложение
по
составу
и
содержанию
выполнения работ по
пункту 9.5 (Билетный
контур) и подпункту
9.10.6 (Квесты и
маршруты)
Технического
задания, в части
конкретных
технических решений
(демонстрирующее
понимание предмета
выполняемых работ)
Характеристика №4
Предложение по
составу
и
содержанию
выполнения работ по
пункту
9.10.7
(Викторины)
Технического
задания, в части
конкретных
технических решений
(демонстрирующее
При наличии предложений по составу
и содержанию работ заявке присваивается:
 100 баллов – наличие всех
алгоритмов и описания,
демонстрирующих понимание
сквозных сценариев.

0 баллов – отсутствие хотя бы одного
алгоритма или формальное
перефразирование ТЗ.
.
20
При наличии предложений по составу
и содержанию работ заявке присваивается:
 100 баллов – полный комплект блоксхем и описания.

0 баллов – неполнота или отсутствие
собственных технических решений.
понимание предмета
выполняемых работ)
Характеристика №5
20
Предложения
по
реализации
интернет-сайта
(главной страницы)
по
пункту
9.1.1
(Дизайн-макеты)
и
подпункту 2 пункта
9.1.3
(Главная
страница)
Технического
задания
3
Квалификаци
я участников
закупки,
в
том
числе
наличие
у
них
финансовых
ресурсов,
оборудовани
я и других
материальны
х ресурсов на
праве
собственност
и или ином
законном
основании,
опыта
10
Наличие у 100
участников
закупки
опыта
работы,
связанного с
предметом
контракта
характеристика
квалификации
участников закупки
№1
(общее
количество
исполненных
договоров)
При наличии предложений по составу
и содержанию работ заявке присваивается:
 100 баллов – представлены все
перечисленные элементы, макет
выполнен на высоком уровне
детализации, соответствует
структуре ТЗ и тематике музея.

100
0 баллов – отсутствие макета,
цветовой схемы или адаптивных
вариантов, либо несоответствие
структуре, заданной в ТЗ.
Оценка заявок осуществляется по формуле,
предусмотренной
п.
20
Положения,
утвержденного
Постановлением
Правительства РФ от 31.12.2021 N 2604.
Количество баллов, присуждаемых по
детализирующему показателю определяется
по формуле:
где:
Хi - значение общего количества
исполненных участником закупки
договоров, содержащееся в предложении
участника закупки, заявка которого
подлежит оценке по детализирующему
показателю «Общее количество
исполненных участником закупки
работы,
связанного с
предметом
контракта, и
деловой
репутации,
специалистов
и
иных
работников
определенног
о
уровня
квалификаци
и
договоров»;
Хmin - минимальное значение общего
количества исполненных участником
закупки договоров, содержащееся в заявках,
подлежащих оценке по детализирующему
показателю «Общее количество
исполненных участником закупки
договоров»;
Хmax - максимальное значение общего
количества
исполненных
участником
закупки договоров, содержащееся в заявках,
подлежащих оценке по детализирующему
показателю
«Общее
количество
исполненных
участником
закупки
договоров».
III.
№
Отдельные положения о применении отдельных критериев оценки, показателей оценки и показателей оценки, детализирующих
показатели оценки, предусмотренных разделом II настоящего приложения
Наименование критерия оценки, показателя
оценки, показателя оценки, детализирующего показатель
оценки, при применении которого устанавливается
положение графой 3
Положение о применении критерия оценки, показателя оценки, показателя
оценки, детализирующего показатель оценки
1
2
3
Порядок оценки заявок на участие в электронном конкурсе осуществляется в соответствии со статьей 32 Закона № 44-ФЗ и с постановлением
Правительства Российской Федерации от 31 декабря 2021 г. № 2604 «Об оценке заявок на участие в закупке товаров, работ, услуг для обеспечения
государственных и муниципальных нужд, внесении изменений в пункт 4 постановления Правительства Российской Федерации от 20 декабря 2021 г. №
2369 и признании утратившими силу некоторых актов и отдельных положений некоторых актов Правительства Российской Федерации» (далее – ППРФ №
2604).
2.1.1
1.
Критерий оценки «Цена
контракта, сумма цен единиц товара,
работы, услуги»
Заявкам, содержащим наилучшее ценовое предложение, а также предложение, равное такому
наилучшему ценовому предложению, присваивается 100 баллов.
Применение показателей оценки по критерию оценки «Цена контракта, сумма цен единиц товары,
работы, услуги» не допускается.
Сумма величин значимости всех применяемых показателей оценки по критерию оценки составляет
100 процентов.
По критерию оценки применяется показатель оценки «Качественные характеристики объекта
закупки».
2.
Критерий
оценки
«Качественные,
функциональные
и
экологические
характеристики объекта закупки»
2.1.
Показатель
«Качественные
характеристики объекта закупки»
В отношении каждого детализирующего показателя устанавливается значимость детализирующего
показателя. Сумма величин значимости всех применяемых детализирующих показателей по показателю
оценки составляет 100 процентов.
Оценка заявок осуществляется по шкале оценки в соответствии с п. 22 ППРФ №2604Оценка заявки
(части заявки) по критерию оценки определяется путем суммирования среднего количества баллов,
присвоенных всеми принимавшими участие в ее рассмотрении и оценке членами комиссии по
осуществлению закупок по показателю оценки, умноженного на значимость показателя оценки. При этом
среднее количество баллов определяется путем суммирования количества баллов, присвоенных каждым
членом комиссии по осуществлению закупок, и последующего деления на количество таких членов.
Детализирующий показатель №1
По детализирующему показателю №1 «Предложение по составу и содержанию выполнения работ по
1
2
- Предложение по составу и
содержанию выполнения работ по пункту
9.8.1 (Редизайн и доработка мобильного
приложения)
и
подпункту
9.10.8
(Дополненная реальность) Технического
задания, в части конкретных технических
решений (демонстрирующее понимание
предмета выполняемых работ)
3
пункту 9.8.1 (Редизайн и доработка мобильного приложения) и подпункту 9.10.8 (Дополненная реальность)
Технического задания, в части конкретных технических решений (демонстрирующее понимание предмета
выполняемых работ)»
К оценке принимается проработанное предложение, которое содержит:
Состав предложения:
1. Алгоритм (блок-схема) взаимодействия пользователя с мобильным приложением при
использовании AR-сценария:
o
запуск сценария;
o
распознавание объекта (изображения, метки или QR-кода);
o
отображение мультимедийного контента (3D-объекты, текст, аудио, видео);
o
интерактивные действия пользователя;
o
завершение и передача результатов в профиль и систему лояльности.
Требования к алгоритму – согласно п. 9.10.8 ТЗ.
2. Алгоритм (блок-схема) работы информационной системы, обеспечивающей
распознавание и обработку AR-событий:
o
обработка запросов от приложения;
o
взаимодействие с единым пользовательским контуром (идентификация, профиль,
согласия);
o
сохранение прогресса, начисление баллов и достижений;
o
защита от повторных начислений и злоупотреблений.
Требования – в соответствии с п. 9.8.1 (интеграция с единым профилем) и п.
9.10.11 (аналитика и защита от дублей).
3. Описание последовательных шагов выполнения работ по доработке мобильного
приложения и внедрению AR-функционала с приведением предполагаемых схем
реализации:
1
2
o
3
выбор технологического стека (платформа, библиотеки для AR);
o
архитектура взаимодействия клиент-сервер;
o
методы обеспечения офлайн-доступа для заранее загруженных AR-материалов;
o
план тестирования на поддерживаемых устройствах.
Объём описания должен подтверждать понимание предмета работ и
соответствие п. 9.8.1 и 9.10.12 ТЗ.
Предложение считается не проработанным и оценивается в ноль баллов, в случаях:
1) отсутствие любого из обязательных элементов или представление формальных отсылок к ТЗ без
собственных решений,
2) предложение участника закупки перефразирует Техническое задание
3) участник закупки указывает что выполнит работы надлежащим образом в соответствии с Техническим
заданием,
4) предложение участника нарушает законодательство Российской Федерации.
5) предложение участника представлено не в полном объеме.
2.1.2.
Детализирующий показатель №2
- Предложение по составу и
содержанию выполнения работ по пункту
9.10.8 (Дополненная реальность) и
подпункту 9.10.12 (Обязательный объем
реализации) Технического задания, в части
конкретных
технических
решений
(демонстрирующее понимание предмета
выполняемых работ)
Предложение предоставляется свободной форме.
Отсутствие в заявке на участие в электронном конкурсе информации по детализирующему показателю не
будет основанием для признания заявки не соответствующей требованиям
По детализирующему показателю № 2 «Предложение по составу и содержанию выполнения работ по
пункту 9.10.8 (Дополненная реальность) и подпункту 9.10.12 (Обязательный объем реализации)
Технического задания, в части конкретных технических решений (демонстрирующее понимание предмета
выполняемых работ)»
Под детализированным предложением понимается проработанное предложение, которое
содержит:
Состав предложения:
1. Алгоритм (блок-схема) действий пользователя при прохождении AR-маршрута:
o
выбор маршрута в приложении;
o
наведение камеры на точки (объекты, метки, изображения);
1
2
o
3
взаимодействие с отображаемыми 3D-объектами и мультимедиа;
o
выполнение заданий, встроенных в маршрут;
o
завершение и получение результата (награда, достижение).
Требования – согласно п. 9.10.8 ТЗ.
2. Алгоритм (блок-схема) работы AR-системы:
o
распознавание и трекинг;
o
рендеринг контента;
o
управление состояниями (загрузка, активность, ошибка);
o
логирование событий и передача данных в аналитику;
o
обеспечение доступной альтернативы для пользователей, не использующих AR.
Требования – в соответствии с п. 9.10.11 и 9.10.12 ТЗ.
3. Описание последовательных шагов выполнения работ по созданию AR-маршрутов:
o
разработка концепций и сценариев;
o
производство мультимедийного контента (2D/3D, аудио, текст);
o
настройка точек и условий активации;
o
тестирование на поддерживаемых устройствах;
o
подготовка и публикация через серверную доставку.
Объём – в соответствии с п. 9.10.12 (не менее 2 маршрутов с 8 заданиями каждый).
Предложение считается не проработанным и оценивается в ноль баллов, в случаях:
1) отсутствие блок-схем или описания этапов работ
2) предложение участника закупки перефразирует Техническое задание
3) участник закупки указывает что выполнит работы надлежащим образом в соответствии с Техническим
заданием,
1
2
3
4) предложение участника нарушает законодательство Российской Федерации.
5) предложение участника представлено не в полном объеме.
Предложение предоставляется в свободной форме.
Отсутствие в заявке на участие в электронном конкурсе информации по детализирующему показателю не
будет основанием для признания заявки не соответствующей требованиям
2.1.3.
Детализирующий показатель № 3
- Предложение по составу и
содержанию выполнения работ по пункту
9.5 (Билетный контур) и подпункту 9.10.6
(Квесты и маршруты) Технического
задания, в части конкретных технических
решений (демонстрирующее понимание
предмета выполняемых работ)
По детализирующему показателю №3 «Предложение по составу и содержанию выполнения работ
по пункту 9.5 (Билетный контур) и подпункту 9.10.6 (Квесты и маршруты) Технического задания, в
части конкретных технических решений (демонстрирующее понимание предмета выполняемых
работ)»
К оценке принимается проработанное предложение, которое содержит:
Состав предложения:
1. Алгоритм (блок-схема) действий пользователя при сканировании QR-кода для получения
билета:
o
открытие камеры/сканера;
o
распознавание QR-кода;
o
проверка статуса билета (активен, использован, отменён);
o
отображение QR-билета и информации о событии;
o
работа в офлайн-режиме (кэширование);
o
защита от доступа к чужому билету.
Требования – согласно п. 9.5 и сценарию С-04 ТЗ.
2. Алгоритм (блок-схема) действий пользователя при прохождении квеста с
использованием QR-кодов:
o
получение задания;
o
сканирование кода в определённой локации;
o
подтверждение выполнения (ответ на вопрос, геолокация);
1
2
3
o
продвижение по маршруту;
o
сохранение прогресса и получение награды.
Требования – в соответствии с п. 9.10.6 ТЗ.
3. Алгоритм (блок-схема) действий администратора при создании и управлении квестами:
o
создание нового квеста / маршрута;
o
добавление заданий с условиями (привязка к QR-кодам, локациям);
o
установка правил прохождения, ограничений, наград;
o
публикация и управление версиями;
o
просмотр статистики прохождения.
Требования – согласно п. 9.10.2–9.10.6 ТЗ.
4. Описание последовательных шагов выполнения работ по интеграции сканирования
QR-кодов в мобильное приложение и билетный контур, а также по реализации
административной панели для управления квестами (архитектура, используемые API,
методы обеспечения идемпотентности и защиты от дублей).
Предложение считается не проработанным и оценивается в ноль баллов, в случаях:
1) отсутствие хотя бы одного алгоритма или формальное перефразирование ТЗ,
2) предложение участника закупки перефразирует Техническое задание,
3) участник закупки указывает что выполнит работы надлежащим образом в соответствии с
Техническим заданием,
4) предложение участника нарушает законодательство Российской Федерации.
5) предложение участника представлено не в полном объеме.
Предложение предоставляется в свободной форме.
Отсутствие в заявке на участие в электронном конкурсе информации по детализирующему
показателю не будет основанием для признания заявки не соответствующей требованиям
2.1.4.
Детализирующий показатель №4
По детализирующему показателю №4 «Предложение по составу и содержанию выполнения работ
1
2
3
по пункту 9.10.7 (Викторины) Технического задания, в части конкретных технических решений
- Предложение по составу и (демонстрирующее понимание предмета выполняемых работ)»
содержанию выполнения работ по пункту
9.10.7 (Викторины) Технического задания,
в части конкретных технических решений
(демонстрирующее понимание предмета
выполняемых работ)
К оценке принимается проработанное предложение, которое содержит:
Состав предложения:
1. Алгоритм (блок-схема) действий пользователя при участии в викторине:
o
выбор викторины из списка;
o
прохождение вопросов (с вариантами ответов);
o
получение результата (количество правильных ответов);
o
начисление баллов и/или достижений;
o
возможность повторного прохождения (если допускается правилами).
Требования – согласно п. 9.10.7 ТЗ.
2. Алгоритм (блок-схема) работы системы викторины:
o
хранение банка вопросов с категориями, сложностью;
o
генерация последовательности вопросов (случайный выбор);
o
проверка ответов и подсчёт баллов;
o
ведение истории прохождений пользователя;
o
защита от повторного начисления баллов за одно прохождение;
o
административный интерфейс для управления вопросами.
Требования – в соответствии с п. 9.10.3–9.10.5 и 9.10.10 ТЗ.
3. Описание последовательных шагов выполнения работ по разработке викторины как
части игровых механик:
o
проектирование модели данных;
o
разработка API для взаимодействия с мобильным приложением и сайтом;
1
2
o
3
создание административной панели для наполнения и настройки викторин;
o
интеграция с программой лояльности (начисление баллов, выдача достижений);
o
тестирование и обеспечение защиты от злоупотреблений.
Предложение считается не проработанным и оценивается в ноль баллов, в случаях:
1) неполнота или отсутствие собственных технических решений,
2) предложение участника закупки перефразирует Техническое задание
3) участник закупки указывает что выполнит работы надлежащим образом в соответствии с
Техническим заданием,
4) предложение участника нарушает законодательство Российской Федерации.
5) предложение участника представлено не в полном объеме.
Предложение предоставляется в свободной форме.
Отсутствие в заявке на участие в электронном конкурсе информации по детализирующему
показателю не будет основанием для признания заявки не соответствующей требованиям
2.1.5
Детализирующий показатель №5
- Предложения по реализации
интернет-сайта (главной страницы) по
пункту 9.1.1 (Дизайн-макеты) и подпункту
2 пункта 9.1.3 (Главная страница)
Технического задания
По детализирующему показателю №5 Предложения по реализации интернет-сайта (главной
страницы) по пункту 9.1.1 (Дизайн-макеты) и подпункту 2 пункта 9.1.3 (Главная страница)
Технического задания)
Под детализированным предложением понимается проработанное предложение, которое должно
содержать:
Состав предложения:
1. Иллюстрированная презентация дизайн-концепции главной страницы основного
сайта, отражающая тематику Театрального музея им. А.А. Бахрушина и соответствующая
брендбуку.
Презентация должна демонстрировать единую стилистику с остальными продуктами
экосистемы (применение дизайн-системы).
2. Макет главной страницы с детальным расположением всех графических элементов,
1
2
3
предусмотренных п. 9.1.3 (пункт 2) ТЗ:
o
глобальная шапка (логотип, меню, поиск, переключатель языка, ссылки на магазин,
медиа, энциклопедию, личный кабинет);
o
Hero-блок с динамическим коллажем событий (связь с CMS);
o
блок «Афиша» с вкладками (Все / Выставки / Экскурсии / Спектакли) и карточками
событий;
o
блок «Коллекции» с анонсом и переходом на страницу коллекций;
o
блок «Музейно-театральный квартал» со слайдером объектов;
o
блок «Новости» с карточками и подпиской на рассылку;
o
промо-блок;
o
витрина интернет-магазина с категориями;
o
подвал (навигация, контакты, соцсети, правовые ссылки).
3. Цветовая схема (палитра) с указанием кодов (HEX/RGB) и обоснованием выбора цветов
(связь с брендом музея, требования доступности контрастности).
4. Адаптивные варианты – минимум для десктопа и мобильных устройств. Для ключевых
блоков должно быть показано, как меняется расположение элементов при переходе на
меньший экран.
Предложение считается не проработанным и оценивается в ноль баллов, в случаях:
1) отсутствие макета, цветовой схемы или адаптивных вариантов, либо несоответствие структуре,
заданной в ТЗ,
2) предложение участника нарушает законодательство Российской Федерации.
3) предложение участника представлено не в полном объеме
Предложение предоставляется в свободной форме.
Отсутствие в заявке на участие в электронном конкурсе информации по детализирующему
1
3.
2
Критерий оценки «Квалификация
участников закупки, в том числе наличие
у них финансовых ресурсов,
оборудования и других материальных
ресурсов на праве собственности или
ином законном основании, опыта работы,
связанного с предметом контракта, и
деловой репутации, специалистов и иных
работников определенного уровня
квалификации»
3.1
Показатель оценки «Наличие у
участников закупки опыта работы,
связанного с предметом контракта»
3.1.1
Детализирующий показатель
оценки: «Общее количество исполненных
участником закупки договоров»
3
показателю не будет основанием для признания заявки не соответствующей требованиям
Сумма величин значимости всех применяемых показателей оценки по критерию оценки составляет
100 процентов.
Для показателя оценки «Наличие у участников закупки опыта работы, связанного с предметом контракта»
применяются детализирующие показатели.
В отношении каждого детализирующего показателя устанавливается значимость детализирующего
показателя. Сумма величин значимости всех применяемых детализирующих показателей по показателю
оценки составляет 100 процентов.
Оценка заявки (части заявки) по показателю оценки определяется путем суммирования среднего количества
баллов, присвоенных всеми принимавшими участие в ее рассмотрении и оценке членами комиссии по
осуществлению закупок по каждому детализирующему показателю, умноженного на значимость
соответствующего детализирующего показателя. При этом среднее количество баллов определяется путем
суммирования количества баллов, присвоенных каждым членом комиссии по осуществлению закупок, и
последующего деления на количество таких членов.
Предметом оценки, является общее количество договоров/контрактов выполненных работ
(оказанных услуг) в области (сфере) по развитию, эксплуатации, обеспечению функционирования или
сопровождению информационных систем и мобильных приложений.
Лучшим условием является наибольшее общее количество договоров/контрактов, в т.ч. с
исполненными требованиями об уплате неустоек (штрафы, пени) (в случае начисления неустоек),
подтвержденные актами сдачи-приемки (актом сдачи-приемки) выполненных работ (оказанных услуг).
Последний акт, составленный при исполнении договора/контракта, должен быть подписан не ранее
чем за 5 лет до даты окончания срока подачи заявок.
К оценке принимаются исполненные участником закупки с учетом правопреемства (в случае
наличия в заявке подтверждающего документа) гражданско-правовые договоры, в том числе заключенные и
исполненные в соответствии с Федеральным законом от 05.04.2013 № 44-ФЗ.
К оценке принимае(ю)тся договор(ы)/контракт(ы), представленный(е) в заявке в полном объеме и со
всеми приложениями в форме электронных документов или в форме электронных образов бумажных
документов.
Все акты сдачи-приемки выполненных работ/оказанных услуг в течение срока действия одного
1
2
3
договора/контракта будут считаться подтверждением одного исполненного договора/контракта.
При отсутствии хотя бы одного документа (договоров(а)/контрактов(а) и/или актов(а) сдачиприемки
выполненных
работ/оказанных
услуг),
входящего
в
состав
исполненных(ого)
договоров(а)/контрактов(а), данный(е) договор(ы)/контракт(ы) не будет(ут) принят(ы) к оценке заявки
участника закупки.
Отсутствие в заявке на участие в электронном конкурсе информации по детализирующему
показателю «Общая цена исполненных участником закупки договоров» не будет основанием для признания
заявки не соответствующей требованиям Закона о контрактной системе и извещения и не влечет принятия
решения об отклонении заявки. Такой участник конкурса получает 0 баллов по данному детализирующему
показателю.

=== ФАЙЛ: Приложение № 2 к извещению Проект контракта 1 с изменениями | docs/0373100047526000034/Приложение № 2 к извещению Проект контракта 1 с изменениями (1).pdf
Приложение № 2 к Извещению
Проект контракта
Контракт №
г. Москва
«___»_________20__ г.
Федеральное государственное бюджетное учреждение культуры «Государственный
центральный театральный музей имени А.А. Бахрушина» (Театральный музей им.
А.А.
Бахрушина),
именуемое
в
дальнейшем
«Заказчик»
в
лице__________________________, действующего____________, с одной стороны, и
__________________________________________, именуемое в дальнейшем «Подрядчик», в
лице ________________ _______________________, действующего на _______________, с
другой стороны, вместе именуемые «Стороны» и каждый в отдельности «Сторона», с
соблюдением требований законодательства Российской Федерации, Федерального закона от
05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для
обеспечения государственных и муниципальных нужд» (далее - Закон № 44-ФЗ), по
результатам
проведения_________________________________________________________
(Идентификационный
код
закупки:
____________________),
Протокол
_______________________________________________________________
(извещение
от
________________________________________________
размещено
в
Единой
информационной системе закупок www.zakupki.gov.ru), заключили настоящий Контракт
(далее – Контракт) о нижеследующем:
1. ПРЕДМЕТ КОНТРАКТА
1.1. Заказчик поручает, а Подрядчик принимает на себя обязательства выполнить работы
по созданию, развитию и вводу в эксплуатацию цифровой экосистемы Федерального
государственного бюджетного учреждения культуры «Государственный центральный
театральный музей имени А. А. Бахрушина», (далее - работа), а Заказчик обязуется принять
работу и оплатить ее.
1.2. Содержание, виды и сроки выполнения работ по Контракту определяются в
соответствии с настоящим Контрактом, Приложением № 1 – «Этапы контракта» и
Приложением № 3 - «Техническое задание».
1.3. Работы по настоящему Контракту осуществляются с использованием материалов
Подрядчика, Подрядчик несет ответственность перед Заказчиком за качество таких
материалов. Стоимость материалов включена в стоимость работ.
1.4. Подрядчик при подписании настоящего Контракта в полном объеме оценил объемы
и срок выполнения работ не имеет замечаний и признает срок достаточным для выполнения
всех работ по Контракту.
1.5. ОКПД 2:
2. ЦЕНА КОНТРАКТА
2.1. Цена
Контракта
составляет
____________
(_______________________________________________________) рублей ___ копеек, в том
числе НДС/НДС не облагается на основании_____________.
Цена настоящего Контракта является твердой, определяется на весь срок исполнения
Контракта и не подлежит изменению, за исключением случаев, установленных Законом № 44ФЗ.
1
Оплата работ по настоящему Контракту осуществляется в рублях Российской
Федерации, путем безналичного перечисления Заказчиком денежных средств на счет
Подрядчика, указанный в настоящем Контракте.
2.2. Цена настоящего Контракта включает в себя установленные законодательством
выплаты, учитывает все расходы Подрядчика, в том числе сопутствующие, связанные с
надлежащим исполнением обязательств по настоящему Контракту, накладные расходы,
необходимые для выполнения Подрядчиком всех обязательств по настоящему Контракту, а
также все налоги, сборы и иные обязательные платежи, установленные законодательством
Российской Федерации, в том числе.
2.3. Подрядчик полностью ознакомился со всеми условиями, которые влияют или могут
повлиять на стоимость и сроки выполнения работ, убедился в характере и содержании работ, а
также все прочие аспекты, которые могут повлиять на ход работ, учел в своих расчетах свои
расходы и прибыль, и в будущем не будет иметь права требования иных платежей, за
исключением предусмотренных в Контракте.
2.4. В случае превышения без согласия Заказчика затрат по сравнению с теми, которые
учитывались при определении цены работ, Подрядчик обязуется компенсировать затраты за
счет собственных средств. Превышение Подрядчиком объемов и стоимости Работ,
произошедшее по вине Подрядчика, Заказчиком не оплачивается.
2.5. Подрядчик несет ответственность за правильность расчета налога на добавленную
стоимость (при наличии НДС).
2.6. Цена Контракта может быть снижена по соглашению Сторон без изменения объема
работ, предусмотренных Техническим заданием (Приложение № 3 к настоящему Контракту) и
иных условий настоящего Контракта, что оформляется Сторонами дополнительным
соглашением к настоящему Контракту.
2.7. Работы, выполненные Подрядчиком с отклонением от условий Контракта,
проектной документации, требований исходных данных, а также нормативных правовых
актов, оформляются актом между Подрядчиком и заказчиком и не подлежат оплате до
устранения Подрядчиком выявленных недостатков, дефектов.
2.8. Источник финансирования: средства субсидии на выполнение государственного
задания.
2.9. Моментом оплаты считается списание денежных средств с лицевого счета
Заказчика, открытого в Федеральном казначействе.
2.10. Заказчик уменьшает сумму, подлежащую уплате Заказчиком юридическому лицу
или физическому лицу, в том числе зарегистрированному в качестве индивидуального
предпринимателя, на размер налогов, сборов и иных обязательных платежей в бюджеты
бюджетной системы Российской Федерации, связанных с оплатой Контракта, если в
соответствии с законодательством Российской Федерации о налогах и сборах такие налоги,
сборы и иные обязательные платежи подлежат уплате в бюджеты бюджетной системы
Российской Федерации Заказчиком.
2.11. В случае уменьшения в установленном порядке ранее доведённых Заказчику
объёмов финансирования, Стороны согласовывают новые условия, в том числе по цене,
срокам, объёмам услуг, предусмотренных Контрактом. При этом сроки оплаты
соответственно переносятся, неустойка (штрафы, пени) не начисляется.
2.12. Авансовый платеж предусмотрен в размере 30% от цены этапа Контракта и
оплачивается на основании выставленного Подрядчиком оригинала счёта в течение 7 (семи)
рабочих дней с момента его выставления.
2.13. Заказчик оплачивает выполненные работы за соответствующий этап за вычетом
ранее выплаченного аванса за соответствующий этап по факту оформленного и подписанного
обеими Сторонами усиленными квалифицированными электронными подписями (далее –
УКЭП) электронного структурированного Универсального передаточного документа (далее УПД) в электронной форме, соответствующего условиям ч. 13 ст. 94 Федерального закона №
44-ФЗ, путем перечисления стоимости выполненных работ с расчетного счета Заказчика на
2
расчетный счет Подрядчика, реквизиты которого указаны в статье «Адреса, реквизиты и
подписи Сторон» Контракта, в течение 7 (семи) рабочих дней с даты подписания Заказчиком
УПД.
2.14. В случае неисполнения или ненадлежащего исполнения Подрядчиком
обязательства, предусмотренного Контрактом, Заказчик производит оплату по Контракту за
вычетом соответствующего размера неустойки (штрафа, пени).
3. СРОКИ ВЫПОЛНЕНИЯ РАБОТ
3.1. Сроки выполнения работ определяются в соответствии с Контрактом, Приложением
№ 1 к Контракту «Этапы выполнения работ», Приложением № 3 к Контракту «Техническое
задание».
4. ПОРЯДОК СДАЧИ-ПРИЕМКИ ВЫПОЛНЕННЫХ РАБОТ
4.1. После завершения этапа выполнения работ Подрядчик в течение 2 (двух) рабочих
дней предъявляет Заказчику для рассмотрения подписанные УКЭП со стороны Подрядчика
электронный структурированный документ о приемке, Акт на передачу исключительных прав,
отчетные документы, предусмотренные Техническим заданием. Заказчик имеет право
подписать представленные Подрядчиком документы, либо представить Подрядчику замечания
к выполненным работам, их результатам и (или) представленным Подрядчиком документам,
не согласовывая их, либо мотивированно отказаться от согласования представленных
Подрядчиком документов в срок, установленный Контрактом. Указанные Заказчиком
недостатки и замечания подлежат устранению Исполнителем за свой счет.
4.2. Не позднее 20 (двадцати) рабочих дней после получения от Подрядчика
документов, указанных в п. 4.1 Контракта, Заказчик рассматривает результаты и осуществляет
приемку выполненных работ по настоящему Контракту на предмет соответствия их объема,
качества требованиям, изложенным в настоящем Контракте.
4.3. Для проверки результатов выполнения работ, выполненных Подрядчиком,
предусмотренных Контрактом, в части их соответствия условиям Контракта Заказчик обязан
провести экспертизу. Экспертиза результатов, предусмотренных Контрактом, может
проводиться Заказчиком своими силами или к ее проведению могут привлекаться эксперты,
экспертные организации. Срок проведения экспертизы равен сроку, установленному для
приемки оказанных услуг в соответствии с п. 4.2 Контракта.
4.4. В случае, если по результатам такой экспертизы установлены нарушения
требований Контракта, не препятствующие приемке выполненных работ, в заключении могут
содержаться предложения об устранении данных нарушений, в том числе с указанием срока
их устранения.
4.5. В случае получения от Заказчика запроса о предоставлении разъяснений
касательно результатов работ , или мотивированного отказа от принятия результатов
выполненных работ, или акта с перечнем выявленных недостатков, необходимых доработок и
сроком их устранения Подрядчик в течение 3 (трех) рабочих дней обязан представить
Заказчику запрашиваемые разъяснения в отношении выполненных работ , или в срок,
установленный в указанном акте (но не менее 3 (трех) рабочих дней), содержащем перечень
выявленных недостатков и необходимых доработок, устранить полученные от Заказчика
замечания/недостатки/произвести доработки и передать Заказчику приведенный в
соответствие
с
предъявленными
требованиями/замечаниями
комплект
отчетной
документации, отчет об устранении недостатков, оказании необходимых доработок, а также
повторный подписанный Подрядчиком УПД для принятия Заказчиком выполненных работ.
3
4.6. Повторное рассмотрение Заказчиком представленных Подрядчиком документов
производится после устранения последним причин отказа в подписании документов в
установленном настоящим пунктом порядке.
Основаниями для отказа в приемке работ является несоответствие проектной
документации,
разработанной
Подрядчиком,
условиям
Контракта,
требованиям
законодательства Российской Федерации, а также указаниям Заказчика.
В случае выявления Заказчиком технических, орфографических, иных ошибок, ошибок в
оформлении, Заказчик имеет право отказать Подрядчику в рассмотрении указанных
документов.
4.7. Любой произведенный Заказчиком платеж не может рассматриваться как
освобождение Подрядчика от устранения выявленных недостатков в оплаченной работе.
5. ПРАВА И ОБЯЗАННОСТИ СТОРОН
5.1. Заказчик обязуется:
5.1.2. Принять выполненные надлежащим образом работы, проверяя их состав и
качество требованиям законодательства Российской Федерации, проектной документации и
условиям Контракта, в порядке и сроки, установленные настоящим Контрактом.
5.1.3. Исполнять другие обязанности, предусмотренные законодательством Российской
Федерации.
5.2. Заказчик вправе:
5.2.1. Осуществлять контроль за ходом и качеством выполняемых работ, соблюдением
сроков их выполнения, качеством предоставленных Подрядчиком материалов, не вмешиваясь
при этом в оперативно-хозяйственную деятельность Подрядчика. Если в результате такого
контроля станет очевидным, что работы не будут выполнены надлежащим образом и (или) в
надлежащие сроки, Заказчик вправе направить Подрядчику требование об устранении
недостатков с указанием срока для их устранения.
5.2.2. В любое время в период выполнения работ требовать от Подрядчика письменного
отчета о ходе выполнения работ, исполнительскую документацию. Подрядчик обязан
предоставить Заказчику указанные документы в трехдневный срок (календарные дни) с даты
получения требования.
5.2.3. Требовать от Подрядчика предоставления надлежащим образом оформленной
отчетной документации и материалов, подтверждающих исполнение обязательств в
соответствии с Техническим заданием (Приложение № 3 к настоящему Контракту) и
законодательством Российской Федерации.
5.2.4. Требовать надлежащего исполнения Подрядчиком своих обязательств по
настоящему Контракту.
5.2.5. Требовать участия в совещаниях, проводимых Заказчиком, должностных лиц
Подрядчика либо их уполномоченных представителей. Решения совещаний в рамках
Контракта обязательны для исполнения Подрядчиком.
5.2.6. В любое время приостановить выполнение работ, письменно уведомив об этом
Подрядчика, в случаях, когда работы по Объекту с нарушением требований норм
законодательства, положений настоящего Контракта, что создает угрозу пригодности и
прочности Объекта, жизни и здоровью людей, сохранности имущества физических и
юридических лиц, безопасности окружающей среды. В случае, если работы остановлены по
вине Подрядчика, Подрядчик не освобождается от ответственности за нарушение сроков
выполнения работ.
5.2.7. Применить штрафные санкции к Подрядчику за неисполнение Контракта.
5.2.8. Осуществлять иные полномочия в рамках исполнения настоящего Контракта.
5.3. Подрядчик обязуется:
4
5.3.1. Соблюдать требования законодательства Российской Федерации.
5.3.2. Выполнить работы в сроки в соответствии с Техническим заданием (Приложение
№ 3 к настоящему Контракту).
5.3.3. В течение 5 (пяти) рабочих дней с момента подписания настоящего Контракта
назначить уполномоченных лиц по исполнению настоящего Контракта и в письменной форме
сообщить об этом Заказчику, указав полный объем предоставленных им полномочий.
5.3.4. Использовать для выполнения работ специалистов, квалификация, опыт,
компетентность которых позволяют осуществлять надлежащее и своевременное выполнение
работ, предусмотренных настоящим Контрактом.
5.3.5. Нести самостоятельную и полную ответственность за организацию охраны и
безопасности труда рабочих на Объекте, привлекать квалифицированный, опытный персонал,
обученный по вопросам охраны труда.
5.3.6. Во время нахождения на Объекте работников (представителей) Подрядчика, а
также привлеченных им для исполнения обязательств по настоящему Контракту лиц,
обеспечить
соблюдение
указанными
лицами
установленного
режима
охраны,
противопожарного режима, правил охраны труда и техники безопасности, в том числе
регулярно проводить необходимый инструктаж указанных лиц и ведение журнала по технике
безопасности.
5.3.7. Подрядчик несет ответственность за неисполнение или ненадлежащее исполнение
обязательств субподрядчиками в рамках выполнения соответствующих работ в соответствии с
гражданским законодательством Российской Федерации. Невыполнение субподрядчиком
обязательств перед Подрядчиком не освобождает Подрядчика от выполнения условий
настоящего Контракта;
5.3.7.1. В случае, если Подрядчик является субъектом малого предпринимательства,
Подрядчик обязуется в письменной форме проинформировать об этом Заказчика в
десятидневный срок с момента заключения настоящего Контракта.
5.3.7.2. В срок не более 5 рабочих дней со дня заключения договора с субподрядчиком,
соисполнителем представить Заказчику:
а) декларацию о принадлежности субподрядчика, соисполнителя к субъектам малого
предпринимательства,
социально
ориентированной
некоммерческой
организации,
составленную в простой письменной форме, подписанную руководителем (иным
уполномоченным лицом) субъекта малого предпринимательства, социально ориентированной
некоммерческой организации и заверенную печатью (при наличии печати);
б) копию договора (договоров), заключенного с субподрядчиком, соисполнителем,
заверенную Подрядчиком.
5.3.8.3. В случае замены субподрядчика, на этапе исполнения Контракта на другого
субподрядчика, соисполнителя представлять Заказчику документы, указанные в п. 5.3.7.2.
настоящего раздела, в течение 5 дней со дня заключения договора с новым субподрядчиком,
соисполнителем.
5.3.8.4. Подрядчик обязан в течение 10 рабочих дней со дня оплаты Подрядчиком
выполненных обязательств по договору с субподрядчиком/соисполнителем представлять
Заказчику следующие документы:
а) копии документов о приемке поставленного товара, выполненной работы, оказанной
услуги, которые являются предметом договора, заключенного между Подрядчиком и
привлеченным им субподрядчиком, соисполнителем.
б) копии платежных поручений, подтверждающих перечисление денежных средств
Подрядчиком субподрядчику, соисполнителю.
5.3.8.5. В случае неисполнения или ненадлежащего исполнения субподрядчиком,
соисполнителем обязательств, предусмотренных договором, заключенным с Подрядчиком,
Подрядчик обязан осуществлять замену субподрядчика, соисполнителя, с которым ранее был
заключен договор, на другого субподрядчика, соисполнителя.
5
5.3.9. Строго исполнять требования миграционного и трудового законодательства
Российской Федерации, в том числе не привлекать и не допускать привлечения
субподрядными организациями иногородних и иностранных рабочих без соответствующей
регистрации и без разрешения на привлечение иностранной рабочей силы.
Использование в качестве рабочей силы лиц, не имеющих гражданства Российской
Федерации, допускается только при наличии соответствующего разрешения, полученного в
региональном подразделении Главного Управления по вопросам миграции Министерства
внутренних дел Российской Федерации, а также регистрации факта пребывания на территории
в Российской Федерации, и только для выполнения видов работ, не требующих наличия
лицензий и разрешений.
5.3.10 Информировать Заказчика о реорганизации, изменении своего юридического
наименования, адреса места нахождения, смене единоличного исполнительного органа,
отзыве доверенностей, а также о других существенных изменениях, влияющие на надлежащее
исполнение взятых на себя обязательств – в течение 3 (трех) дней сообщать о
соответствующих изменениях Заказчику. Уведомление должно быть направлено в
письменной форме, в порядке, предусмотренном Контрактом.
В случае изменения банковских реквизитов Подрядчик обязан в течение 3 (трех) дней с
момента их изменения в письменной форме сообщить об этом Заказчику, с указанием новых
реквизитов. В противном случае все риски, связанные с перечислением Заказчиком денежных
средств на указанный в настоящем Контракте счет Подрядчика, несет Подрядчик.
5.3.11 При проведении Заказчиком или компетентными органами (по согласованию с
Заказчиком) проверок по целевому использованию бюджетных средств, представить все
необходимые документы и информацию по выполнению работ на Объекте.
5.3.12. Выполнить в полном объеме свои обязательства, предусмотренные в других
статьях настоящего Контракта.
5.3.13. Нести ответственность за привлеченные для выполнения работ, предусмотренных
настоящим Контрактом, субподрядные организации.
5.3.14. В течение 1 (одного) дня со дня получения информировать Заказчика о всех,
полученных от уполномоченных органов, предписаниях, предостережениях, иных актах
реагирования, а также о фактах возбуждения в отношении Подрядчика и субподрядчиков.
5.3.15. Обеспечить наличие разрешений (лицензий) (при необходимости) на
производство работ, а также специалистов, аттестованных в установленном порядке
Минкультуры России у всех лиц (субподрядчиков), привлекаемых к исполнению работ по
Контракту.
5.4. Подрядчик имеет право:
5.4.1. Обращаться к Заказчику с запросами в целях надлежащего исполнения своих
обязательств по Контракту.
5.4.2. Привлечь к исполнению своих обязательств других лиц (субподрядчиков) в
порядке, установленном настоящим Контрактом.
6. ИНТЕЛЛЕКТУАЛЬНАЯ СОБСТВЕННОСТЬ
6.1. Исключительные права на результаты интеллектуальной деятельности, не способные
к правовой охране, полученные при выполнении Контракта, принадлежат Музею.
6.2. Исключительные права на объекты интеллектуальной собственности, способные к
правовой охране, полученные при выполнении Контракта, принадлежат Музею.
6.3. Передача исключительного права осуществляется на весь срок действия
исключительного права, без ограничения территории использования, с правом Заказчика
использовать результаты интеллектуальной деятельности любым не запрещенным законом
способом.
6
6.4. Вознаграждение за создание результатов интеллектуальной деятельности и передачу
исключительного права включено в цену настоящего Контракта. Отдельная плата за передачу
исключительного права, документации и иных материалов не взимается.
6.5. Подрядчик обязан согласовать с Заказчиком необходимость, перечень и порядок
использования при выполнении работ по Контракту результатов интеллектуальной
деятельности или средств индивидуализации (далее – результаты интеллектуальной
деятельности), исключительные права на которые принадлежат Заказчику.
6.6. Каждая Сторона остается единственным владельцем исключительных прав на
результаты интеллектуальной деятельности, принадлежащие Стороне до подписания
Контракта и предоставляемые такой Стороной другой Стороне для целей выполнения условий
Контракта.
6.7. Заказчик вправе использовать и распоряжаться всеми видами проектной и отчетной
документации, разработанной и выпущенной при исполнении Контракта. Права на указанную
документацию и другие материальные объекты, полученные при выполнении работ,
переходят к Заказчику со дня подписания Сторонами соответствующего акта сдачи-приемки и
оплаты выполненных работ.
6.8. Подрядчику запрещается использование сведений, предоставленных ему
Заказчиком, для любых других целей, кроме определенных в Контракте. Заказчик со своей
стороны обязуется сохранять полную конфиденциальность о методах и способах реализации
Подрядчиком контрактных обязательств.
6.9. Подрядчик гарантирует, что выполненные по Контракту работы и полученные
результаты не нарушают интеллектуальных прав (авторских, патентных и иных
интеллектуальных прав) третьих лиц на территории Российской Федерации.
6.10. Подрядчик гарантирует, что:
6.10.1. является обладателем необходимых прав на передаваемые результаты либо
получил от авторов и иных правообладателей права, достаточные для исполнения настоящего
Контракта и передачи исключительного права Заказчику;
6.10.2. передача исключительного права Заказчику не нарушает прав и законных
интересов третьих лиц;
6.10.3. в созданных результатах не использованы объекты, права на которые
ограничивают предусмотренное настоящим Контрактом использование, если такое
использование прямо не согласовано с Заказчиком;
6.10.4. привлеченные авторы, работники и субподрядчики надлежащим образом
передали Подрядчику права на созданные ими результаты, необходимые для их последующей
передачи Заказчику;
6.10.5. после передачи исключительного права Заказчик сможет использовать
созданные результаты без необходимости получения дополнительных согласий или выплаты
дополнительных вознаграждений третьим лицам, за исключением платежей, прямо указанных
в перечне сторонних компонентов и согласованных Заказчиком.
6.11. В случае привлечения для исполнения обязательств по Контракту третьих лиц
Подрядчик обязан предусмотреть во всех договорах, заключаемых с третьими лицами, как
непосредственно привлеченными Подрядчиком, так и иными привлеченными для выполнения
работ по Контракту третьими лицами, условия, о том, что все исключительные права на
результаты выполненных работ возникают у Заказчика.
6.12. Подрядчик несет имущественную ответственность за нарушение интеллектуальных
прав (авторских, патентных и иных интеллектуальных прав) третьих лиц. В случае
возникновения претензий или исков, предъявленных Заказчику со стороны третьих лиц на
территории Российской Федерации, вызванных нарушением их интеллектуальных прав
(авторских, патентных и иных интеллектуальных прав), в связи с выполнением Подрядчиком
обязательств по Контракту, Заказчик немедленно информирует об этом Подрядчика; проводит
предварительные переговоры с третьей стороной; обеспечивает Подрядчику возможность
провести за счет Подрядчика любые мероприятия по урегулированию претензий, исков и
7
судебных разбирательств. Подрядчик обязуется урегулировать такие претензии своими
силами и за свой счёт, а также возместить Заказчику все убытки, вызванные нарушением
Подрядчиком интеллектуальных прав (авторских, патентных и иных интеллектуальных прав)
третьих лиц на территории Российской Федерации.
7. ОТВЕТСТВЕННОСТЬ СТОРОН
7.1. За неисполнение или ненадлежащее исполнение своих обязательств по настоящему
Контракту Стороны несут ответственность в соответствии с законодательством Российской
Федерации.
7.2. Каждая Сторона должна исполнять свои обязанности, вытекающие из настоящего
Контракта надлежащим образом, оказывая другой Стороне всевозможное содействие в
выполнении ею своих обязательств. Сторона, нарушившая свои обязательства по настоящему
Контракту, должна без промедления устранить допущенные нарушения.
7.3. В случае просрочки исполнения Подрядчиком обязательств (в том числе
гарантийного обязательства), предусмотренных Контрактом, а также в иных случаях
неисполнения или ненадлежащего исполнения Подрядчиком обязательств, предусмотренных
Контрактом, Заказчик направляет Подрядчику требование об уплате неустоек (штрафов,
пеней).
7.4. Размер штрафа устанавливается Контрактом в порядке, установленном настоящей
статьей, в том числе рассчитывается как процент Цены Контракта, или в случае, если
Контрактом предусмотрены этапы исполнения Контракта, как процент цены этапа исполнения
Контракта (далее - Цена Контракта (Этапа)).
7.5. Пеня начисляется за каждый день просрочки исполнения Подрядчиком
обязательства, предусмотренного Контрактом, начиная со дня, следующего после дня
истечения установленного Контрактом срока исполнения обязательства, в размере одной
трехсотой действующей на дату уплаты пени ключевой ставки Центрального банка
Российской Федерации от Цены Контракта (отдельного этапа исполнения Контракта),
уменьшенной на сумму, пропорциональную объему обязательств, предусмотренных
Контрактом (соответствующим отдельным этапом исполнения Контракта) и фактически
исполненных Подрядчиком, за исключением случаев, если законодательством Российской
Федерации установлен иной порядок начисления пени.
7.6. За каждый факт неисполнения или ненадлежащего исполнения Подрядчиком
обязательств, предусмотренных Контрактом, за исключением просрочки исполнения
обязательств, предусмотренных Контрактом, размер штрафа устанавливается в следующем
порядке:
а) 10 процентов цены Контракта (этапа) в случае, если цена Контракта (этапа) не
превышает 3 млн. рублей;
б) 5 процентов цены Контракта (этапа) в случае, если цена Контракта (этапа) составляет
от 3 млн. рублей до 50 млн. рублей (включительно);
в) 1 процент цены Контракта (этапа) в случае, если цена Контракта (этапа) составляет от
50 млн. рублей до 100 млн. рублей (включительно);
г) 0,5 процента цены Контракта (этапа) в случае, если цена Контракта (этапа) составляет
от 100 млн. рублей до 500 млн. рублей (включительно);
д) 0,4 процента цены Контракта (этапа) в случае, если цена Контракта (этапа) составляет
от 500 млн. рублей до 1 млрд. рублей (включительно);
е) 0,3 процента цены Контракта (этапа) в случае, если цена Контракта (этапа) составляет
от 1 млрд. рублей до 2 млрд. рублей (включительно).
7.7. За каждый факт неисполнения или ненадлежащего исполнения Подрядчиком
обязательства, предусмотренного Контрактом, которое не имеет стоимостного выражения (в
том числе в случае непредоставления Подрядчиком в срок, предусмотренный Контрактом,
8
размер штрафа устанавливается (при наличии в Контракте таких обязательств) в следующем
порядке:
а) 1000 рублей, если цена Контракта не превышает 3 млн. рублей;
б) 5000 рублей, если цена Контракта составляет от 3 млн. рублей до 50 млн. рублей
(включительно);
в) 10000 рублей, если цена Контракта составляет от 50 млн. рублей до 100 млн. рублей
(включительно);
г) 100000 рублей, если цена Контракта превышает 100 млн. рублей.
7.8. За каждый факт неисполнения Заказчиком обязательств, предусмотренных
Контрактом, за исключением просрочки исполнения обязательств, предусмотренных
Контрактом, размер штрафа устанавливается в следующем порядке:
а) 1000 рублей, если цена Контракта не превышает 3 млн. рублей (включительно);
б) 5000 рублей, если цена Контракта составляет от 3 млн. рублей до 50 млн. рублей
(включительно);
в) 10000 рублей, если цена Контракта составляет от 50 млн. рублей до 100 млн. рублей
(включительно);
г) 100000 рублей, если цена Контракта превышает 100 млн. рублей.
7.9. В случае просрочки исполнения Заказчиком обязательств, предусмотренных
Контрактом, а также в иных случаях неисполнения или ненадлежащего исполнения
Заказчиком обязательств, предусмотренных Контрактом, Подрядчик вправе потребовать
уплаты неустоек (штрафов, пеней). Пеня начисляется за каждый день просрочки исполнения
обязательства, предусмотренного Контрактом, начиная со дня, следующего после дня
истечения, установленного Контрактом срока исполнения обязательства. Такая пеня
устанавливается в размере 1/300 (одной трехсотой) действующей на дату уплаты пеней
ключевой ставки Центрального банка Российской Федерации от не уплаченной в срок суммы.
7.10. За неисполнение условия о привлечении к исполнению Контракта субподрядчиков
из числа субъектов малого предпринимательства, социально ориентированных
некоммерческих организаций, штраф устанавливается в размере 5 (пяти процентов) объема
такого привлечения, установленного Контрактом.
7.11. Общая сумма начисленных штрафов за неисполнение или ненадлежащее
исполнение Подрядчиком обязательств, предусмотренных Контрактом, не может превышать
цену Контракта.
7.12. Общая сумма начисленных штрафов за ненадлежащее исполнение Заказчиком
обязательств, предусмотренных Контрактом, не может превышать цену Контракта.
7.13. Размер штрафа определяется в соответствии с Правилами определения размера
штрафа, начисляемого в случае ненадлежащего исполнения Заказчиком, неисполнения или
ненадлежащего исполнения Подрядчиком обязательств, предусмотренных Контрактом (за
исключением просрочки исполнения обязательств Заказчиком, поставщиком (подрядчиком,
исполнителем), утвержденными постановлением Правительства Российской Федерации от
30.08.2017 № 1042.
7.14. Сторона освобождается от уплаты неустойки (штрафа, пени), если докажет, что
неисполнение или ненадлежащее исполнение обязательства, предусмотренного Контрактом,
произошло вследствие непреодолимой силы или по вине другой стороны.
7.15. Заказчик освобождается от ответственности за просрочку исполнения обязанности
по оплате выполненных по Контракту работ в случае непоступления денежных средств из
федерального бюджета.
7.16. Заказчик освобождается от ответственности за просрочку исполнения обязанности
по оплате выполненных по Контракту работ в порядке и на условиях, определенных
Гражданским кодексом РФ и Бюджетным кодексом РФ.
7.17. Уплата неустойки не освобождает Подрядчика от исполнения своих обязательств
по Контракту и от возмещения убытков, причиненных неисполнением или ненадлежащим
исполнением своих обязательств по Контракту.
9
7.18. В случае применения административными органами имущественных санкций к
Заказчику, если они явились результатом нарушения Подрядчиком своих обязанностей или
совершения Подрядчиком иных действий, влекущих применение к Заказчику имущественных
санкций, Подрядчик компенсирует Заказчику убытки (в том числе, но не ограничиваясь,
штрафы, пени (неустойки) в размере взысканных с Заказчика санкций.
7.19. Подрядчик несет ответственность за нарушение качества выполненных работ по
Контракту.
7.20. Подрядчик несет ответственность за нарушение начального и конечного сроков
выполнения работ.
7.21. Подрядчик несет ответственность в случае предъявления к Заказчику претензий и
судебных исков со стороны третьих лиц, связанных с ненадлежащим выполнением
Подрядчиком работ по настоящему Контракту.
7.22. В случае причинения ущерба имуществу Заказчика, причинения вреда работникам
Заказчика, вследствие виновных действий представителей Подрядчика, а также привлеченных
им для исполнения обязательств по настоящему Контракту работников, Подрядчик несет
ответственность в соответствии с законодательством Российской Федерации.
7.23. В случае изменения Подрядчиком технологии выполнения работ и/или применение
технологических процессов, предусмотренных ГОСТами и Сводами правил, но не
ухудшающих результат работ, вся полнота ответственности за качество работ, а также
дополнительные расходы, которые могут за собой повлечь такие изменения, в полном объеме
возлагается на Подрядчика.
7.24 Заказчик не несет ответственности перед третьими лицами (в частности, по уплате
вознаграждения, по возмещению вреда, и т.д.), привлеченными Подрядчиком по собственной
инициативе для выполнения работ по настоящему Контракту (если такой факт будет иметь
место).
7.25. Применение предусмотренных настоящим разделом санкций не лишает Заказчика
права на возмещение в полном объеме убытков, возникших в результате неисполнения
(ненадлежащего исполнения) Подрядчиком своих обязательств.
8. ОБСТОЯТЕЛЬСТВА НЕПРЕОДОЛИМОЙ СИЛЫ
8.1. Под обстоятельствами непреодолимой силы понимают чрезвычайные и
непредотвратимые обстоятельства, которые могут возникнуть после заключения настоящего
Контракта в результате непредвиденных или непреодолимых Сторонами событий.
Стороны освобождаются от ответственности за частичное или полное неисполнение
своих обязательств по настоящему Контракту, если это неисполнение явилось следствием
обстоятельств непреодолимой силы, а именно: наводнение, пожар, землетрясение, взрыв,
шторм, оседание почвы, эпидемия и иные явления природы, а также действия объективных
внешних факторов (военные действия, гражданские волнения, восстания, вторжения,
террористические акты, диверсии, ограничения перевозок, запретительные акты
государственных органов и т.п.), в том числе, если нарушение произошло в связи с мерами,
принятыми в Российской Федерации для предотвращения распространения инфекции,
вызванной, в частности, 2019-nCoV, запрет торговых операций, в том числе с отдельными
странами, вследствие принятия международных санкций и другие, не зависящие от воли
Сторон обстоятельства, при условии, что эти обстоятельства непосредственно повлияли на
исполнение обязательств по настоящему Контракту.
К таким обстоятельствам не относятся, в частности, нарушение Подрядчиком или его
контрагентами законодательства Российской Федерации, нарушение обязанностей со стороны
контрагентов Подрядчика, отсутствие на рынке нужных для исполнения товаров, отсутствие у
должника необходимых денежных средств.
8.2. Сторона, для которой создалась невозможность исполнения обязательств по
настоящему Контракту, вследствие обстоятельств непреодолимой силы, должна о
10
наступлении этих обстоятельств известить в письменном виде другую Сторону без
промедления, но не позднее 10 (десяти) дней с момента их наступления. Извещение должно
содержать данные о наступлении и характере обстоятельств и возможных их последствиях, а
также подтверждающие документы компетентных государственных органов. Сторона также
без промедления, однако, не позднее 10 (десяти) дней, должна известить другую Сторону в
письменном виде о прекращении этих обстоятельств.
Не извещение или несвоевременное извещение другой Стороны Стороной, для которой
создалась невозможность исполнения обязательств по настоящему Контракту, о наступлении
обстоятельств, освобождающих ее от ответственности, влечет за собой утрату права для этой
Стороны ссылаться на эти обстоятельства.
8.3. В случае наступления обстоятельств, указанных в п. 11.1 настоящего Контракта,
Стороны согласовывают свои дальнейшие действия по выполнению настоящего Контракта.
9. ГАРАНТИЙНЫЕ ОБЯЗАТЕЛЬСТВА
9.1. Подрядчик гарантирует качество выполнения всех работ в соответствии с
Приложением № 3 «Техническое задание», действующими нормами законодательства и
своевременное устранение недостатков и дефектов, выявленных при приемке объекта и в
период гарантийного срока эксплуатации Объекта.
9.2. Гарантийный срок на выполняемые по настоящему Контракту работы составляет
6 (шесть) месяцев с даты подписания Сторонами документа о приемке этапа № 3.
В случае, если Заказчиком в течение срока предоставления гарантий качества работ
будут выявлены недостатки и дефекты, допущенные Подрядчиком в процессе производства
работ, либо являющиеся следствием ненадлежащего качества работ, предусмотренных
настоящим Контрактом (в том числе в результате использования материалов ненадлежащего
качества, отступления от технологии производства работ и пр.), Подрядчик обязуется своими
силами и за свой счет устранить выявленные нарушения.
9.2.1. Подрядчик несет ответственность за недостатки (дефекты), обнаруженные в
пределах гарантийного срока, если не докажет, что они произошли вследствие нормального
износа объекта.
9.3. При обнаружении в течение гарантийного срока недостатков Заказчик должен
заявить о них Подрядчику в разумный срок после их обнаружения.
В течение 10 (десяти) дней со дня получения Подрядчиком уведомления об
обнаруженных недостатках на объекте Стороны составляют акт, в котором фиксируются
обнаруженные недостатки.
Для составления вышеуказанного акта Стороны вправе привлечь независимую
экспертную организацию, эксперта в данной области. Экспертиза может быть назначена также
по требованию любой из Сторон. При этом расходы на соответствующую экспертизу несет
виновная Сторона.
В случае неполучения Подрядчиком уведомления или уклонения Подрядчика в течение
10 (десяти) дней от составления, указанного в настоящем пункте акта, Заказчик вправе
составить односторонний акт.
Заказчик вправе самостоятельно либо с привлечением третьих лиц устранить дефекты
(недостатки) за свой счет, с последующим возмещением своих расходов на устранение
дефектов (недостатков) Подрядчиком. Подрядчик возмещает расходы Заказчика на
устранение дефектов (недостатков) в течение 20 (двадцати) дней со дня получения
соответствующего уведомления Заказчика.
9.4. Течение гарантийного срока прерывается на все время, на протяжении которого
Объект не мог эксплуатироваться вследствие недостатков, за которые отвечает Подрядчик.
В случае если ущерб, нанесенный объекту, является следствием ненадлежащего его
содержания (эксплуатации) собственником или иным законным владельцем объекта в период
гарантийного срока, ущерб Подрядчиком не возмещается.
11
9.5. Обеспечение гарантийных обязательств не предоставляется.
10. ОБЕСПЕЧЕНИЕ ИСПОЛНЕНИЯ ОБЯЗАТЕЛЬСТВ
ПО КОНТРАКТУ
10.1. Обеспечение исполнения Контракта предоставляется. Подрядчик вносит
обеспечение исполнения Контракта в размере 30 % от цены Контракта в форме безотзывной
независимой гарантии/путем внесения денежных средств.
10.2. Участник закупки, с которым заключается контракт по результатам определения
поставщика (подрядчика, исполнителя) в соответствии с пунктом 1 части 1 статьи 30
Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров,
работ, услуг для обеспечения государственных и муниципальных нужд», освобождается от
предоставления обеспечения исполнения Контракта, в том числе с учетом положений статьи
37 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок
товаров, работ, услуг для обеспечения государственных и муниципальных нужд», в случае
предоставления таким участником закупки информации, содержащейся в реестре контрактов,
заключенных заказчиками, и подтверждающей исполнение таким участником (без учета
правопреемства) в течение трех лет до даты подачи заявки на участие в закупке трех
контрактов, исполненных без применения к такому участнику неустоек (штрафов, пеней).
Такая информация представляется участником закупки до заключения Контракта в случаях,
установленных Федеральным законом от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере
закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» для
предоставления обеспечения исполнения контракта. При этом сумма цен таких контрактов
должна составлять не менее начальной (максимальной) цены контракта, указанной в
извещении об осуществлении закупки и документации о закупке.
10.3. Обеспечение гарантийных обязательств не представляется.
10.4. Способ обеспечения исполнения Контракта, срок действия независимой гарантии
определяется участником закупки, с которым заключается Контракт, самостоятельно в
соответствии с требованиями Закона о контрактной системе.
10.5. ВАРИАНТ 1 (Используется при предоставлении Исполнителем обеспечения
исполнения Контракта в форме независимой гарантии. Независимая гарантия должна
соответствовать требованиям, установленным ст.45 Закона о контрактной системе).
Исполнение контракта обеспечивается предоставлением независимой гарантии.
Независимая гарантия должна соответствовать требованиям, установленным ст.45 Закона о
контрактной системе, а также предусматривать условие о праве Заказчика на бесспорное
списание денежных средств со счета гаранта при отсутствии оснований для отказа в
удовлетворении требования бенефициара, предусмотренных Гражданским кодексом
Российской Федерации, если гарантом в срок не более чем 10 (десять) рабочих дней не
исполнено требование Заказчика об уплате денежной суммы по независимой гарантии,
направленное до окончания срока ее действия.
ВАРИАНТ 2 (Используется при предоставлении Исполнителем обеспечения
исполнения Контракта путем внесения денежных средств на счет Заказчика).
Денежные средства, внесенные в обеспечение исполнения обязательств по Контракту,
включая обязательства по уплате предусмотренных Контрактом неустоек (штрафов, пеней),
перечислены Подрядчиком в размере, установленном в настоящей статье Контракта, на счет
Заказчика, указанный в статье «Адреса, реквизиты и подписи Сторон». Факт внесения
Подрядчиком денежных средств в обеспечение исполнения обязательств по Контракту
подтверждается платежным поручением с отметкой банка о проведении платежа и списании
средств со счета Подрядчика и поступлением денежных средств на счет Заказчика. Внесенные
12
Подрядчиком в обеспечение исполнения обязательств Подрядчика по Контракту денежные
средства обеспечивают исполнение Подрядчиком всех обязательств Подрядчика по
Контракту, в том числе обязательств, связанных с неисполнением либо ненадлежащим
исполнением Контракта Подрядчиком, включая обязательства по возмещению Заказчику
убытков по уплате Заказчику неустоек (штрафов, пеней), начисленных Заказчиком в связи с
неисполнением либо ненадлежащим исполнением Подрядчиком предусмотренных
Контрактом обязательств. В случае неисполнения или ненадлежащего исполнения
Подрядчиком обеспеченных внесением денежных средств обязательств, Заказчик имеет право
удержать из внесенных Подрядчиком денежных средств сумму, равную сумме денежных
средств, которую Подрядчик обязан уплатить Заказчику в качестве неустойки (штрафов,
пеней) или в качестве возмещения убытков, либо иной сумме денежных средств, подлежащей
уплате Подрядчиком Заказчику по Контракту. Удержанные Заказчиком денежные средства
переходят в собственность Заказчика. Денежные средства, в том числе часть этих денежных
средств, в случае уменьшения размера обеспечения исполнения Контракта в соответствии с
частями 7, 7.1 и 7.2 статьи 96 Закона о контрактной системе возвращаются Заказчиком
Подрядчику по истечении срока действия данного обеспечения в срок до пятнадцати
календарных дней с даты исполнения Подрядчиком обязательств, предусмотренных
Контрактом. Денежные средства возвращаются на банковский счет Поставщика, указанный в
статье «Адреса, реквизиты и подписи Сторон».
10.6. Обеспечение исполнения Контракта распространяется на случаи неисполнения
или ненадлежащего исполнения Исполнителем обязательств по Контракту, неуплаты
Подрядчиком неустоек (штрафов, пеней), предусмотренных Контрактом, а также убытков,
понесенных Заказчиком в связи с неисполнением или ненадлежащим исполнением
Подрядчиком своих обязательств по Контракту.
10.7. В ходе исполнения Контракта Подрядчик вправе изменить способ обеспечения
исполнения Контракта и (или) предоставить Заказчику взамен ранее предоставленного
обеспечения исполнения Контракта новое обеспечение исполнения Контракта, размер
которого может быть уменьшен в порядке и случаях, которые предусмотрены частями 7.2
и 7.3 ст. 96 Закона о контрактной системе.
10.8. Подрядчик вправе изменить способ обеспечения гарантийных обязательств и
(или) предоставить Заказчику взамен ранее предоставленного обеспечения гарантийных
обязательств новое обеспечение гарантийных обязательств.
10.9. В случае отзыва в соответствии с законодательством Российской Федерации у
банка, предоставившего независимую гарантию в качестве обеспечения исполнения
Контракта, лицензии на осуществление банковских операций предоставить новое обеспечение
исполнения Контракта не позднее одного месяца со дня надлежащего уведомления
Заказчиком Подрядчика о необходимости предоставить соответствующее обеспечение. Размер
такого обеспечения может быть уменьшен в порядке и случаях, которые предусмотрены
частями 7, 7.1, 7.2 и 7.3 статьи 96 Закона о контрактной системе. За каждый день просрочки
исполнения Исполнителем обязательства, предусмотренного частью 30 статьи 34 Закона о
контрактной системе, начисляется пеня в размере, определенном в порядке, установленном в
соответствии с Контрактом.
11. КОНФИДЕНЦИАЛЬНОСТЬ
11.1. Любая информация, предоставляемая Подрядчику Заказчиком, а также
информация, к которой Подрядчик получает доступ, либо которая становится известной
Подрядчику в связи с выполнением настоящего Контракта, вне зависимости от формы ее
13
хранения и способа документирования (далее по тексту - Информация) является
конфиденциальной.
Информация не будет считаться конфиденциальной, если Подрядчик докажет, что она
была им получена из публичных источников.
11.2. Подрядчик обязуется хранить указанную в п. 11.1 настоящего Контракта
Информацию на условиях полной конфиденциальности, не разглашать и не использовать ее
ни для какой иной цели, кроме как для выполнения настоящего Контракта.
11.3. За действия (бездействия) своих сотрудников Подрядчик несет перед Заказчиком и
третьими лицами ответственность в полном объеме, и в случае причинения его сотрудниками
ущерба обязан возместить Заказчику и (или) третьим лицам все причиненные такими
действиями убытки.
12. РАЗРЕШЕНИЕ СПОРОВ
12.1. Все споры и разногласия, возникающие между Сторонами из настоящего Контракта
или в связи с ним, разрешаются путем переговоров, а в случае недостижения согласия - в
претензионном порядке.
Заинтересованная Сторона обязана направить другой Стороне претензию. Претензия и
ответ на претензию направляется с использованием единой информационной системы путем
направления электронных уведомлений. Такие уведомления формируются с использованием
единой информационной системы, подписываются усиленной электронной подписью лица,
имеющего право действовать от имени Заказчика, Подрядчика, и размещаются в единой
информационной системе без размещения на официальном сайте.
12.2. Срок рассмотрения и ответа на претензию – 7 (семь) календарных дней с даты
надлежащего уведомления другой Стороны.
12.3. Неполучение ответа на претензию в установленный настоящим Контрактом срок
рассматривается как отказ в удовлетворении претензии.
12.5. В случае отказа в удовлетворении претензии, либо неполучения ответа на
претензию, либо получение ответа вне срока, установленного п. 12.2 настоящего Контракта,
Сторона, направившая претензию, вправе передать спор на разрешение в Арбитражный суд
города Москвы.
12.6. По всем вопросам, не урегулированным настоящим Контрактом, но прямо или
косвенно вытекающим из отношений Сторон по нему, а также затрагивающих
имущественные интересы и деловую репутацию Сторон, Стороны будут руководствоваться
Законом № 44-ФЗ и законодательством Российской Федерации.
13. ПОРЯДОК ИЗМЕНЕНИЯ И РАСТОРЖЕНИЯ
КОНТРАКТА
13.1. При исполнении настоящего Контракта изменение его условий не допускается, за
исключением случаев, прямо предусмотренных ст. 95 Закона № 44-ФЗ.
13.2. Настоящий Контракт может быть расторгнут:
- по соглашению Сторон;
- в судебном порядке;
- одностороннее расторжение в следующих случаях:
13.2.1. Основания расторжения Контракта в связи с односторонним отказом от исполнения
контракта по инициативе Заказчика:
13.2.2. Выполнение услуг ненадлежащего качества, если недостатки не могут быть устранены
в приемлемый для Заказчика срок.
13.2.3. Неоднократное (от двух и более раз) нарушение сроков и объемов оказания услуг,
предусмотренных контрактом, включая график оказания услуг (календарный план).
14
13.2.4. Подрядчик не приступает к исполнению Контракта в срок, установленный Контрактом,
или нарушает график оказания услуг, предусмотренный Контрактом, или выполняет услуги
так, что окончание их оказания к сроку, предусмотренному Контрактом, становится явно
невозможно, либо в ходе оказания услуг стало очевидно, что они не будут выполнены
надлежащим образом в установленный Контрактом срок.
13.2.5. Если отступления в оказании услуг от условия Контракта или иные недостатки
результата оказанных услуг в установленный Заказчиком разумный срок не были устранены
либо являются существенными и неустранимыми.
13.2.6. В случае, если по результатам экспертизы оказанных услуг с привлечением экспертов,
экспертных организаций, в заключении эксперта, экспертной организации будут
подтверждены нарушения условий Контракта.
13.2.7. Если в ходе исполнения Контракта установлено, что Подрядчик и (или) поставляемый
товар перестали соответствовать установленным извещением об осуществлении закупки и
(или) документацией о закупке, требованиям к участникам данной закупки и (или)
поставляемому товару или при определении исполнителя Подрядчик представил
недостоверную информацию о своем соответствии и (или) соответствии поставляемого товара
требованиям, указанным в пп. «а» п. 1 ч. 15 ст. 95 Закона о контрактной системе, что
позволило ему стать победителем данной закупки.
13.2.8. В случае если Подрядчик отказывается от согласования новых условий Контракта при
наступлении обстоятельств, указанных в статье 2 Контракта;
13.3. Основания расторжения Контракта в связи с односторонним отказом от исполнения
контракта по инициативе Подрядчика:
13.4. Неоднократные (от двух и более раз) нарушения Заказчиком сроков оплаты оказанных
услуг, допущенные по вине Заказчика.
13.5. Неоднократный (от двух и более раз) необоснованный отказ Заказчика от приемки
выполненных работ. При этом необоснованным отказом считается отказ Заказчика от
подписания УКЭП электронного структурированного УПД в срок, предусмотренный
Контрактом, без письменного объяснения причин такого отказа.
13.6. Расторжение Контракта по соглашению сторон определяется в порядке, установленном
действующим гражданским законодательством Российской Федерации. Сторона, которой
направлено предложение о расторжении Контракта по соглашению сторон, должна дать
письменный ответ, по существу, в срок, не превышающий 5 (пяти) календарных дней с даты
его получения.
13.7. Расторжение Контракта в одностороннем порядке осуществляется с соблюдением
требований частей 8 - 25 статьи 95 Закона о контрактной системе.
13.8. Решение об одностороннем расторжении настоящего Контракта направляется второй
Стороне в оригинале по адресу второй Стороны, указанному в статье 15 Контракта.
14. КАЗНАЧЕЙСКОЕ СОПРОВОЖДЕНИЕ КОНТРАКТА
14.1. В соответствии со ст. 242.25 Бюджетного кодекса Российской Федерации (далее – БК
РФ) авансовые платежи по настоящему Контракту подлежат казначейскому сопровождению.
14.2. Согласно ст. 242.23 БК РФ в настоящий Контракт включаются следующие положения:
1) об открытии в Федеральном казначействе участниками казначейского сопровождения
лицевых счетов для осуществления и отражения операций со средствами участников
казначейского сопровождения в соответствии с порядком, утвержденным Федеральным
казначейством;
2) о представлении в Федеральное казначейство документов, установленных порядком
санкционирования, предусмотренным п. 4 ст. 242.23 БК РФ (далее – Порядок
санкционирования);
3) об указании в контрактах (договорах), распоряжениях, а также в документах,
установленных порядком санкционирования, предусмотренным п. 4 ст. 242.23 БК РФ,
15
идентификатора государственного контракта. Порядок формирования указанного
идентификатора устанавливается Министерством финансов Российской Федерации;
4) о ведении раздельного учета результатов финансово-хозяйственной деятельности по
каждому государственному контракту, договору (соглашению), контракту (договору) в
соответствии с порядком, определенным Правительством Российской Федерации;
5) о формировании в установленных Правительством Российской Федерации случаях
информации о структуре цены государственного контракта, контракта (договора), суммы
средств, предусмотренной договором (соглашением), в порядке и по форме, установленным
Министерством финансов Российской Федерации (далее - расходная декларация);
6) о соблюдении запретов, установленных п. 3 ст. 242.23 БК РФ на перечисление средств с
лицевого счета:
- в качестве взноса в уставный (складочный) капитал другого юридического лица (дочернего
общества юридического лица), вклада в имущество другого юридического лица (дочернего
общества юридического лица), не увеличивающего его уставный (складочный) капитал, если
нормативными правовыми актами (правовыми актами), регулирующими порядок
предоставления средств, не предусмотрена возможность их перечисления указанному
юридическому лицу (дочернему обществу юридического лица) на счета, открытые им в
учреждении Центрального банка Российской Федерации или в кредитной организации;
- в целях размещения средств на депозитах, а также в иные финансовые инструменты, за
исключением случаев, установленных федеральными законами или нормативными правовыми
актами Правительства Российской Федерации, законами субъектов Российской Федерации
(муниципальными правовыми актами представительных органов муниципальных
образований), устанавливающими порядок организации и осуществления бюджетного
процесса в субъектах Российской Федерации (муниципальных образованиях);
- на счета, открытые в учреждении Центрального банка Российской Федерации или в
кредитной организации юридическому лицу, за исключением:
оплаты обязательств юридического лица в соответствии с валютным законодательством
Российской Федерации;
оплаты обязательств юридического лица по оплате труда с учетом начислений и социальных
выплат, иных выплат в пользу работников, а также выплат лицам, не состоящим в штате
юридического лица, привлеченным для достижения цели, определенной при предоставлении
средств;
оплаты фактически поставленных юридическим лицом товаров, выполненных работ,
оказанных услуг, источником финансового обеспечения которых являются средства,
предоставляемые на основании государственных контрактов, договоров (соглашений),
контрактов (договоров), в случае, если юридическое лицо не привлекает для поставки товаров,
выполнения работ, оказания услуг иных юридических лиц, а также при условии
представления документов, установленных соответствующим порядком санкционирования,
предусмотренным п. 4 ст. 242.23 БК РФ, подтверждающих возникновение денежных
обязательств юридических лиц, и (или) иных документов, предусмотренных
государственными контрактами, договорами (соглашениями), контрактами (договорами) или
нормативными правовыми актами (правовыми актами), регулирующими порядок
предоставления средств;
возмещения произведенных юридическим лицом расходов (части расходов) при условии
представления документов, указанных в абзаце четвертом настоящего подпункта, копий
платежных документов, подтверждающих оплату произведенных юридическим лицом
расходов (части расходов), а также государственных контрактов, договоров (соглашений),
контрактов (договоров) или нормативных правовых актов (правовых актов), регулирующих
порядок предоставления средств, если условиями государственных контрактов, договоров
(соглашений), контрактов (договоров) предусмотрено возмещение произведенных
юридическим лицом расходов (части расходов);
- на счета, открытые в учреждении Центрального банка Российской Федерации или в
16
кредитной организации юридическим лицам, заключившим с участником казначейского
сопровождения контракты (договоры) за исключением контрактов (договоров), заключаемых
в целях приобретения услуг связи по приему, обработке, хранению, передаче, доставке
сообщений электросвязи или почтовых отправлений, коммунальных услуг, электроэнергии,
гостиничных услуг, услуг по организации и осуществлению перевозки грузов и пассажиров
железнодорожным транспортом общего пользования, авиационных и железнодорожных
билетов, билетов для проезда городским и пригородным транспортом, подписки на
периодические издания, в целях аренды, осуществления работ по переносу (переустройству,
присоединению) принадлежащих участникам казначейского сопровождения инженерных
сетей, коммуникаций, сооружений, а также в целях проведения государственной экспертизы
проектной документации и результатов инженерных изысканий, проведения строительного
контроля уполномоченным федеральным органом исполнительной власти или
подведомственным
ему
государственным
учреждением
в
соответствии
с законодательством Российской
Федерации
о
градостроительной
деятельности,
осуществления страхования в соответствии со страховым законодательством, в целях
приобретения услуг по приему платежей от физических лиц, осуществляемых платежными
агентами;
7) о соблюдении в установленных Правительством Российской Федерации случаях
положений, предусмотренных ст. 242.24 БК РФ.
14.3. Подрядчик обязан до получения денежных средств по настоящему Контракту открыть
в территориальном органе Федерального казначейства лицевой счет участника казначейского
сопровождения для учета операций с целевыми средствами по настоящему Контракту.
14.4. Подрядчик обязан предоставить Заказчику реквизиты открытого лицевого счета и
сведения, необходимые для включения настоящего Контракта в установленном порядке в
документы казначейского сопровождения, не позднее 5 рабочих дней с даты заключения
Контракта.
14.5. Перечисление аванса и иных денежных средств, подлежащих казначейскому
сопровождению, осуществляется Заказчиком на лицевой счет Подрядчика, открытый в
соответствии с пунктом 14.3. настоящего раздела.
14.6. Подрядчик обязан использовать целевые средства исключительно для исполнения
обязательств по настоящему Контракту, соблюдать режим лицевого счета, требования к
раздельному учету операций и представлять в территориальный орган Федерального
казначейства документы, необходимые для санкционирования операций.
14.7. Подрядчик обязан обеспечить открытие лицевых счетов участника казначейского
сопровождения для привлекаемых им соисполнителей и субподрядчиков в случаях,
установленных законодательством Российской Федерации и условиями казначейского
сопровождения.
14.8. В случае изменения реквизитов лицевого счета либо иных сведений, имеющих
значение для казначейского сопровождения, Подрядчик обязан уведомить Заказчика в течение
5 рабочих дней с даты такого изменения.
15. ЗАКЛЮЧИТЕЛЬНЫЕ ПОЛОЖЕНИЯ
15.1. Настоящий Контракт вступает в силу со дня заключения и действует по
____________________, а в части гарантийных обязательств – до полного их исполнения
Сторонами.
17
15.2. Окончание срока действия настоящего Контракта не освобождает Стороны от
ответственности за нарушение условий настоящего Контракта.
15.3. Любое уведомление, требование или иное сообщение, направляемое Заказчиком
или Подрядчиком друг другу по Контракту, должно быть совершено в письменной форме.
Такое уведомление или сообщение считается направленным надлежащим образом, если оно
доставлено адресату:
 заказным письмом, указанному в ст. 16 Контракта, и за подписью полномочного лица,
и/или
 в виде сканированного документа по адресу электронной почты, указанному в ст. 16
Контракта, и/или
 нарочным или любым другим способом, позволяющим соблюсти простую
письменную форму, и/или
 путем отправки с использованием функционала единой информационной системы
(http://www.zakupki.gov.ru/) при подписании усиленной электронной подписью лица,
имеющего право действовать от имени Заказчика.
15.4. Уведомления и сообщения, отсылаемые по почте, направляются на почтовый адрес
Стороны, указанный в Контракте или по месту нахождения организации, указанному в
ЕГРЮЛ.
15.5. Уклонение Стороны от получения почтового отправления, равно как и отсутствие
Стороны по адресу, указанному в Контракте или по месту нахождения организации,
указанному в ЕГРЮЛ, не будут расцениваться как ненадлежащее уведомление Стороны. В
этом случае уведомление считается полученным в сроки, установленные почтовой
организацией в качестве нормативных.
15.6. Уведомление почтовой программы о невозможности доставки электронного письма
Стороне по адресу электронной почты, указанному в Контракте, не будут расцениваться как
ненадлежащее уведомление Стороны. В этом случае уведомление считается полученным в
день отправления.
15.7. Все изменения и дополнения к настоящему Контракту действительны при условии,
если они совершены в письменной форме и подписаны обеими Сторонами.
15.8. Настоящий Контракт составлен в форме электронного документа, подписанного
электронными цифровыми подписями Сторон.
15.9. Во всем, что не предусмотрено настоящим Контрактом, Стороны руководствуются
законодательством Российской Федерации.
15.10. Приложения, указанные в настоящем Контракте и являющиеся его неотъемлемой
частью:
Приложение № 1 – Этапы исполнения контракта;
Приложение № 2 – Спецификация;
Приложение № 3 – Техническое задание.
16. АДРЕСА, РЕКВИЗИТЫ И ПОДПИСИ СТОРОН:
Заказчик:
Подрядчик:
Федеральное государственное бюджетное
учреждение культуры «Государственный
центральный театральный музей им. А. А.
Бахрушина»
Юридический
адрес:
115054,
ул. Бахрушина, 31/12, стр.1
Москва,
18
ИНН 7705042669
КПП 770501001
ОГРН 1037739292470
ОКТМО 45376000
ОКПО 02194824
Банковские реквизиты:
ОКЦ №1 ГУ БАНКА РОССИИ ПО ЦФО//УФК
ПО Г.МОСКВЕ
г. Москва
Единый
казначейский
счет
40102810545370000003
Казначейский счет 03214643000000017300
УФК ПО Г. МОСКВЕ (ТЕАТРАЛЬНЫЙ
МУЗЕЙ
ИМ.
А.А.
БАХРУШИНА,
БАХРУШИНСКИЙ ТЕАТРАЛЬНЫЙ МУЗЕЙ,
БАХРУШИНСКИЙ
МУЗЕЙ,
БТМ,
л/с
20736Х29810)
(Внимание! В лицевом счёте «X» печатать в
латинице)
БИК ТОФК 004525988
Адрес электронной почты:
mail@bakhrushinmuseum.ru
Заказчик_______________/_________________
Подрядчик
/
_______/_____________________
19
Приложение № 1 к Контракту
№ ________________________
от «___» ____________
ЭТАПЫ ИСПОЛНЕНИЯ КОНТРАКТА
Этап
Этап 1
Декабрьский
запуск
Этап 2
Майский
запуск
Этап 3
Запуск
Экосистемы
Срок
выполнения
работ
Принимаемый результат
С даты
заключения
контракта до
20.12.2026
Русскоязычный основной сайт:
главная страница, афиша и
страницы событий, новости,
страницы всех филиалов,
справочные сведения,
действующий билетный контур,
CMS, применимые официальные
и юридические страницы.
Редизайн действующего
интернет-магазина с сохранением
его авторизации, личного
кабинета и торговых сценариев.
Базовая аналитика,
инфраструктура и
эксплуатационные средства,
нагрузка по пункту 14.1.1,
проверки силами Подрядчика,
обучение и передача результатов.
С даты
приемки этапа
1 до 31.05.2027
Полный основной сайт с поиском,
сайт Фонда на общей CMS,
витрина коллекции; единые SSO
и ЛК, CRM, лояльность,
уведомления, аналитика и
интеграции. RU/EN-интерфейсы
вводимых продуктов. Миграция и
привязка к единому профилю
покупок начиная с публичного
запуска этапа 1. Проверки
выпуска силами Подрядчика,
обучение и передача результатов.
C даты
приемки 2
этапа до
01.11.2027
Весь обязательный объём ТЗ,
включая готовые контентные
продукты по пункту 9.10.12.
Комплексные испытания,
независимые аудиты
информационной безопасности и
цифровой доступности, опытная
эксплуатация по пункту 18.6,
полная передача исходников,
прав, документации, доступов и
Цена этапа, с том
числе НДС/НДС не
облагается
20
Этап
Срок
выполнения
работ
Принимаемый результат
Цена этапа, с том
числе НДС/НДС не
облагается
знаний.
90
Этап 4
календарных
Стабилизация дней с даты
экосистемы
приёмки этапа
3
Усиленный мониторинг,
круглосуточное реагирование на
критические инциденты,
диагностика, консультации и
сопровождение обновлений в
установленном объёме.
Отчётность, актуальные
эксплуатационные материалы и
передача сопровождения.
Заказчик
Подрядчик
_______________/___________________
__________________/__________________
___
21
Приложение № 2 к Контракту
№ ________________________
от «___» ____________
СПЕЦИФИКАЦИЯ
Заказчик
Подрядчик
_______________/___________________
__________________/__________________
___
22
Приложение № 3 к Контракту
№ ________________________
от «___» ____________
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Заказчик:
Подрядчик:
______________________//
МП
______________________ //
МП
23

=== ФАЙЛ: Приложение № 1 к извещению Техническое_задание_на_цифровую_экосистему_Музея_23_09_2026 (1) | docs/0373100047526000034/Приложение № 1 к извещению Техническое_задание_на_цифровую_экосистему_Музея_23_09_2026 (1).pdf
Приложение № ___
к Контракту № ___
от «___» __________ 20__ г.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на выполнение работ по созданию, развитию и вводу в эксплуатацию
цифровой экосистемы Федерального государственного бюджетного учреждения
культуры
«Государственный центральный театральный музей имени А. А. Бахрушина»
Москва, 2026
1
1. Общие положения
1.1. Наименование объекта закупки
Выполнение работ по созданию, развитию и вводу в эксплуатацию цифровой
экосистемы Федерального государственного бюджетного учреждения культуры
«Государственный центральный театральный музей имени А. А. Бахрушина» (далее
соответственно — Работы, Музей, Заказчик, Экосистема).
1.2. Заказчик и Подрядчик
Заказчиком является Федеральное государственное бюджетное учреждение
культуры «Государственный центральный театральный музей имени А. А. Бахрушина».
Подрядчик определяется по результатам закупки, проводимой в соответствии с
Федеральным законом от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере
закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд».
1.3. Предмет и результат Работ
Предметом Работ является создание целостной цифровой экосистемы Музея,
объединяющей публичные цифровые продукты, пользовательские сервисы, интернетмагазин, мобильное приложение, билетные сценарии, единый личный кабинет, программу
лояльности, игровые и мультимедийные механики, клиентские коммуникации, аналитику,
интеграции и эксплуатационный контур.
Результатом Работ является не процесс разработки и не совокупность
разрозненных программных модулей, а введенная в эксплуатацию, документированная,
безопасная, наблюдаемая и пригодная к дальнейшему развитию Экосистема, в которой
реализованы предусмотренные настоящим техническим заданием (далее – ТЗ) сквозные
пользовательские, административные и эксплуатационные сценарии.
Закрытие задач, предоставление отчетов о трудозатратах или демонстрация
отдельных экранов не являются самостоятельным подтверждением выполнения Работ.
Результат принимается по требованиям ТЗ, комплекту передаваемых результатов и
приемочным сценариям.
Заказчик является единственным лицом, уполномоченным утверждать дизайн,
набор технологий и оценивать соответствие требованиям, и его замечания обязательны к
исполнению в рамках ТЗ.
1.4. Место и сроки выполнения Работ
Место выполнения Работ: по месту нахождения Подрядчика, на объектах и в
информационной инфраструктуре Заказчика, а также дистанционно с использованием
согласованных защищенных каналов доступа.
Работы выполняются в четыре самостоятельных оплачиваемых этапа:
1. Этап 1 — Декабрьский запуск
2. Этап 2 — Майский запуск
3. Этап 3 — Запуск Экосистемы
4. Этап 4 — Стабилизация экосистемы
Сроки и принимаемые результаты этапов определяются пунктом 17.2.1 настоящего
ТЗ. Периоды выполнения комплексов работ и контрольные точки устанавливаются
2
пунктами 17.2.2 и 17.3. Каждый этап завершается отдельной приёмкой в соответствии с
разделом 18.
Стоимость и порядок оплаты этапов устанавливаются Контрактом.
1.5. Разграничение детализирующих документов
Настоящее ТЗ определяет обязательный состав, объем, характеристики и
результаты Работ. Подрядчик разрабатывает частные технические задания, спецификации,
схемы, протоколы и иные детализирующие документы только в пределах настоящего ТЗ.
Такие документы не могут исключать обязательные требования, уменьшать или
увеличивать объем закупки, изменять состав Экосистемы, переносить обязательный
функционал за пределы Контракта либо ухудшать установленные показатели.
1.6. Общие требования к измеримости
Тип требования
Функциональное
Способ описания
Уникальный идентификатор,
роль, канал, предусловия и
входные данные, действия
пользователя и системы, основной
результат, конечное состояние
данных, исключения и
отрицательные ветки, интеграции,
аналитические события и
применимые требования
доступности
Подтверждение
Паспорт сквозного сценария,
протокол испытаний, снимки
интерфейса, журналы и
трассировка,
идентификаторы операций и
объектов, сведения из
интегрируемых систем
Техническая документация,
Техническое
протокол испытаний, анализ
конфигурации
Показатель качества, допустимый Отчет тестирования,
Качественное
уровень дефектности
классификация дефектов
Доступность, мониторинг,
Данные мониторинга,
Эксплуатационное
резервное копирование, RTO/RPO протокол восстановления
Передача прав, исходников,
Акты, реестры, документы о
Правовое
учетных записей и лицензий
правах и доступах
Все функциональные требования должны быть связаны с одним или несколькими
сквозными сценариями и приёмочными проверками. Формулировки «корректно»,
«удобно», «успешно», «интуитивно понятно» и аналогичные оценочные формулировки
применяются только совместно с однозначно проверяемым критерием.
Архитектурный контур,
интерфейс, формат данных, среда
Для применимых пользовательских интерфейсов проверяются состояния загрузки,
отсутствия данных, частичного результата, ошибки, недоступности внешней системы,
успешного завершения, истечения срока действия и недостаточности прав или
разрешений.
1.7. Термины и сокращения
Термин
Экосистема
Определение
Совокупность взаимосвязанных цифровых продуктов,
сервисов, данных, интеграций и средств эксплуатации сайтов
Музея, на условиях п.3.
3
Термин
Единый
пользовательский
контур
Техническое задание
(ТЗ)
Частное техническое
задание (ЧТЗ)
Личный кабинет (ЛК)
Система управления
содержанием (CMS)
Программный
интерфейс (API)
Единый вход
Цифровая копия
Источник достоверных
данных
Тестовая среда
Предпромышленная
среда
Промышленная среда
Наблюдаемость
Перечень программных
компонентов (SBOM)
Критический сценарий
Внешняя зависимость
Программа и методика
испытаний (ПМИ)
Определение
Общий механизм идентификации, авторизации, профиля,
согласий и настроек пользователя.
Настоящее Техническое задание, приложенное к Контракту
Документ, детализирующий требования настоящего
Технического задания применительно к отдельной системе,
подсистеме, компоненту, интеграции или виду работ.
Интерфейс самообслуживания пользователя для доступа к
билетам, заказам, бонусам, обращениям и настройкам.
Средство создания, редактирования, согласования и
публикации материалов Экосистемы.
Документированный способ автоматизированного
взаимодействия информационных систем.
Авторизация пользователя в нескольких продуктах без
повторного ввода учетных данных в пределах общего сеанса.
Файл или набор файлов, воспроизводящих внешний вид,
звук, движение либо иные свойства музейного материала.
Система или ответственное подразделение, данные которого
признаются первичными для конкретной сущности.
Изолированная среда для функционального, интеграционного
и регрессионного тестирования разрабатываемых изменений
с использованием тестовых или обезличенных данных.
Среда проверки версии перед промышленным выпуском,
максимально близкая к промышленной конфигурации.
Среда, в которой Система эксплуатируется реальными
пользователями и обрабатывает реальные данные.
Метрики, журналы, трассировка, панели и оповещения,
позволяющие оценивать и диагностировать состояние
системы.
Реестр сторонних библиотек, программных компонентов,
версий и лицензий, включенных в поставку.
Пользовательский, административный или
эксплуатационный сценарий, нарушение которого делает
невозможным предоставление ключевой услуги или
безопасную эксплуатацию.
Система, услуга, данные, доступ или решение, не
находящиеся под непосредственным управлением
Подрядчика по Контракту.
Документ, разрабатываемый Подрядчиком на основании
настоящего ТЗ и матрицы приёмки и утверждаемый
Заказчиком до проведения испытаний. ПМИ определяет
состав, порядок и условия проверок, используемые тестовые
данные, ожидаемые результаты, критерии прохождения
испытаний и необходимые доказательства соответствия
Экосистемы требованиям ТЗ.
4
Термин
Паспорт сквозного
сценария
Обязательный сценарий
Составной сценарий
Инцидент
Дефект
Время реакции
Обходное решение
Восстановление
работоспособности
Целевое время
восстановления (RTO)
Требования к уровню
обслуживания (SLA)
Окончательное
исправление
Определение
Включённое в ПМИ структурированное описание
приёмочной проверки отдельного сквозного сценария,
содержащее условия проведения, роли и каналы, тестовые
данные, последовательность действий, ожидаемые
результаты, отрицательные ветки, перечень доказательств и
критерий «пройдено / не пройдено».
Сценарий, который должен быть успешно пройден для
итоговой приёмки независимо от присвоенной ему
критичности
Сценарий, включающий несколько веток, каналов или
операций. Критичность его отдельных веток может
различаться и фиксируется в паспорте сценария
Незапланированное событие, приведшее либо способное
привести к нарушению доступности, безопасности,
целостности данных или выполнения установленного
сценария Экосистемы.
Несоответствие программного кода, конфигурации,
интеграции, интерфейса или документации требованиям
ТЗ либо утверждённой документации.
Период от автоматического обнаружения или регистрации
инцидента до подтверждения его получения
ответственным специалистом, назначения исполнителя и
начала диагностики.
Временная мера, позволяющая восстановить выполнение
затронутого сценария до окончательного устранения
причины. Наличие обходного решения не означает
окончательного устранения дефекта.
Восстановление выполнения установленных контрольных
пользовательских и интеграционных сценариев,
подтверждённое мониторингом и проверкой.
Максимально допустимое время от автоматического
обнаружения или регистрации инцидента — в
зависимости от того, что произошло раньше, — до
восстановления работоспособности затронутого сервиса
или контрольного сценария по установленному в ТЗ
критерию.
Установленная настоящим ТЗ совокупность измеримых
требований к доступности сервисов, срокам уведомления,
реакции, восстановления работоспособности,
предоставления обходного решения и окончательного
исправления, а также к режиму поддержки, эскалации,
контролю и отчётности.
Устранение первопричины дефекта с выпуском
проверенной версии и подтверждением отсутствия
повторного проявления.
5
Термин
Целевая точка
восстановления данных
(RPO)
Определение
Максимально допустимый период, за который могут быть
утрачены данные вследствие инцидента, отсчитываемый
назад от момента автоматического обнаружения или
регистрации инцидента до последней доступной
согласованной точки восстановления. RPO не является
периодичностью резервного копирования: применяемая
схема резервирования должна обеспечивать
установленное значение RPO.
2. Правовые и стратегические основания
2.1. Нормативные правовые акты и документы стратегического планирования
При выполнении Работ должны учитываться применимые требования
законодательства Российской Федерации и документы стратегического планирования,
включая нормативные документы, указанные в Приложении № 5, в том числе, но не
ограничиваясь:











Конституция Российской Федерации, включая право каждого на участие в культурной
жизни, пользование учреждениями культуры и доступ к культурным ценностям, а
также обязанность заботиться о сохранении исторического и культурного наследия;
Закон Российской Федерации от 9 октября 1992 г. № 3612-1 «Основы законодательства
Российской Федерации о культуре»;
Федеральный закон от 26 мая 1996 г. № 54-ФЗ «О Музейном фонде Российской
Федерации и музеях в Российской Федерации»;
Федеральный закон от 27 июля 2006 г. № 152-ФЗ «О персональных данных»;
Федеральный закон от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных
технологиях и о защите информации»;
Федеральный закон от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере
закупок товаров, работ, услуг для обеспечения государственных и муниципальных
нужд»;
Указ Президента Российской Федерации от 24 декабря 2014 г. № 808 «Об утверждении
Основ государственной культурной политики» с последующими изменениями;
Указ Президента Российской Федерации от 9 ноября 2022 г. № 809 «Об утверждении
Основ государственной политики по сохранению и укреплению традиционных
российских духовно-нравственных ценностей»;
Указ Президента Российской Федерации от 7 мая 2024 г. № 309 «О национальных
целях развития Российской Федерации на период до 2030 года и на перспективу до
2036 года»;
Стратегия государственной культурной политики на период до 2030 года,
утвержденная распоряжением Правительства Российской Федерации от 11 сентября
2024 г. № 2501-р;
иные применимые нормативные правовые акты, национальные стандарты и локальные
акты Заказчика.
2.2. Связь Экосистемы с установленными законом функциями Музея
В соответствии с Федеральным законом от 26 мая 1996 г. № 54-ФЗ «О Музейном
фонде Российской Федерации и музеях в Российской Федерации» музей является
6
некоммерческим учреждением культуры, созданным для хранения, изучения и
публичного представления музейных предметов и музейных коллекций. Экосистема
является цифровым средством выполнения и развития указанных функций, а также
поддержки научно-исследовательской, культурно-просветительской, образовательной и
выставочной деятельности Музея.
Экосистема должна обеспечивать:













свободный и равный доступ к театральному наследию независимо от места
проживания, возраста, уровня подготовки, физических возможностей и используемого
устройства;
публичное представление музейных предметов, музейных коллекций, выставок,
истории театра и деятельности Музея в цифровой среде;
представление коллекции не только как совокупности отдельных музейных предметов,
но и как целостной истории театра, раскрывающей взаимосвязи между людьми,
спектаклями, театрами, эпохами, художественными направлениями и историческими
обстоятельствами;
сохранение и представление материального и нематериального театрального наследия,
включая изображения музейных предметов, аудио- и видеозаписи, голоса,
исполнительские традиции, режиссёрские и сценографические практики, устные
истории, воспоминания, сведения о пластике, интонации и иных особенностях
театрального искусства;
отражение развития театрального искусства от его исторических истоков до
современности, включая взаимосвязь театральных школ, направлений, поколений и
культур народов России;
доступ пользователей к достоверной научной, просветительской и справочной
информации;
создание, систематизацию, описание, публикацию и контролируемое использование
цифровых копий, метаданных и связанных материалов;
документирование происхождения цифровых материалов, источников сведений,
истории изменений, правовых оснований использования и ответственных за
подготовку и публикацию;
поддержку различных образовательных и исследовательских маршрутов для детей,
школьников, студентов, взрослых пользователей, исследователей и
профессионального театрального сообщества;
возможность самостоятельного изучения коллекций, поиска смысловых и
исторических связей, формирования пользовательских подборок и возвращения к
ранее выбранным материалам;
использование мультимедийных, интерактивных и иммерсивных способов
представления материалов, включая цифровые истории, виртуальные маршруты,
аудиовизуальные материалы, игровые и иные форматы в объёме, установленном
функциональными требованиями настоящего ТЗ;
однозначное разграничение документально подтверждённых сведений, научной
интерпретации, художественной реконструкции, гипотезы и автоматически
сформированных материалов;
разграничение доступа, резервное копирование, защиту и сохранность цифровых
данных;
7

представление музейного квартала и филиалов Музея как открытого культурного
пространства, объединяющего наследие, современный театр, образование,
исследование и общественный диалог;
 расширение аудитории Музея и формирование устойчивой связи пользователя с
культурным наследием;
 развитие цифрового взаимодействия как самостоятельной формы доступа к наследию
и одновременно как средства формирования интереса к очному посещению Музея и
знакомству с подлинными музейными предметами.
Цифровое представление музейного предмета не должно подменять его научное
описание или создавать у пользователя ложное представление о свойствах, атрибуции,
происхождении либо степени подлинности предмета. Художественные реконструкции и
гипотетические материалы должны иметь явное обозначение и сопровождаться указанием
источников, на которых они основаны.
2.3. Сохранение и укрепление традиционных российских духовно-нравственных
ценностей
Экосистема должна содействовать реализации государственной политики по
сохранению и укреплению традиционных российских духовно-нравственных ценностей,
установленной Указом Президента Российской Федерации от 9 ноября 2022 г. № 809,
посредством предоставления посетителям Музея и пользователям его цифровых сервисов
доступной, достоверной и содержательной информации о театральном наследии России,
создания условий для его изучения и осмысления, а также формирования интереса к
культуре, истории российского театра и очному посещению Музея. Для предметной
области театрального музея приоритетное значение имеют историческая память и
преемственность поколений, единство народов России, высокие нравственные идеалы,
гуманизм, служение Отечеству, созидательный труд, приоритет духовного над
материальным, взаимопомощь и взаимоуважение, достоинство человека и крепкая семья.
Связь с указанными ценностями должна обеспечиваться не декларативным
размещением лозунгов, а содержанием, пользовательскими сценариями и
функциональными возможностями Экосистемы, в том числе посредством:

достоверного и содержательного представления истории российского театра как
части исторической памяти и единого культурного пространства страны;

сохранения цифровой памяти о деятелях театра, спектаклях, театральных школах,
творческих профессиях, музейных предметах, коллекциях и связанных с ними
человеческих судьбах;

представления вклада различных народов, регионов, театральных традиций и
поколений в развитие российского театрального искусства;

раскрытия театрального наследия не как застывшего собрания предметов, а как
живого культурного процесса, связывающего прошлое, настоящее и будущее;

создания семейных, детских, молодёжных и межпоколенческих маршрутов и
образовательных материалов;

обеспечения доступа к культурному наследию для жителей регионов,
маломобильных пользователей и лиц, не имеющих возможности посетить Музей
очно;
8

использования понятных способов представления материалов для пользователей
разного возраста и уровня подготовки без необоснованного упрощения или
искажения научного содержания;

рассказа о музейных предметах через связанные с ними события, судьбы,
нравственный выбор, творческий и созидательный труд людей;

поддержки самостоятельного изучения, осмысления и обсуждения театрального
наследия;

представления современного театрального сообщества и раскрытия
преемственности между историческим наследием и современными творческими
практиками;

формирования интереса к подлинным музейным предметам, очному посещению
Музея, театру и самостоятельному изучению отечественной культуры.
Контентные, поисковые и рекомендательные механизмы Экосистемы не должны
искажать исторические сведения, подменять научно обоснованное музейное описание
рекламными формулировками, скрывать происхождение информации либо создавать
ложную атрибуцию музейных предметов.
2.4. Роль цифровой трансформации
Создание Экосистемы рассматривается как организационное и технологическое
развитие деятельности Музея, а не только как замена сайта. Организационное развитие
предполагает выстраивание единых процессов создания и публикации контента,
взаимодействия с посетителями, управления данными и цифровыми сервисами, а также
закрепление ролей и ответственности подразделений Музея в рамках этих процессов.
Экосистема должна объединить цифровые точки взаимодействия с посетителем,
обеспечить измеримость результатов, сокращение ручных операций, доступность
культурного наследия, сохранность цифровых материалов, а также возможность её
последующего сопровождения, модификации и развития Заказчиком самостоятельно либо
с привлечением иных лиц без обязательного участия первоначального Подрядчика.
3. Исходное состояние и объект автоматизации
3.1. Объект автоматизации
Объектом автоматизации являются процессы цифрового взаимодействия Музея с
посетителями, исследователями, участниками образовательных и просветительских
программ, волонтерами, партнерами и сотрудниками, а также процессы управления
контентом, билетными сценариями, программой лояльности, обращениями, аналитикой и
эксплуатацией цифровых сервисов.
3.2. Исходные цифровые продукты и системы
На дату начала Работ Заказчик использует или развивает отдельные цифровые
продукты и системы, состав и состояние которых подлежат обследованию:
Компонент
Основной сайт
Исходное состояние
Утвержденные материалы по
новому дизайну
9
Требуемое действие
Создание нового решения,
миграция и ввод в эксплуатацию
Компонент
Исходное состояние
Сайт Фонда
Действующий сайт,
ориентировочным объёмом
около 20 страниц
Интернет-магазин
Мобильное
приложение
Реализован на платформе 1СБитрикс
Существующее
кроссплатформенное
приложение на Flutter и
связанная серверная часть;
состояние подтверждается
аудитом
Требуемое действие
Перенос под управление общей
CMS на платформе 1С-Битрикс с
сохранением действующего
дизайна, содержания и
пользовательского поведения, без
редизайна
Обследование, редизайн,
доработка и интеграция
Аудит, редизайн, доработка и
интеграция; сохранение либо
контролируемая замена серверной
части по результатам аудита
Является самостоятельным
компонентом экосистемы и
интегрируется с остальными
сервисами
Интеграция без изменения
Билетная система
Внешний билетный контур
внутренней логики, если иное не
предусмотрено
Существующая
Интеграция обезличенных
Корпоративный
корпоративная
технических инцидентов, их
портал
инфраструктура
номеров и статусов
Интеграция обращений, чата,
Существующая клиентская
клиентского профиля,
CRM
инфраструктура
согласованных событий и
доступных пользователю статусов
Интеграция в согласованном
1С
Учетные системы Музея
составе, включая магазин
Создание единой модели событий
Аналитика
Отдельные счетчики и отчеты
и управленческих отчетов
Программа
Целевой сервис отсутствует
Создание единого сервиса для
лояльности
либо фрагментарен
всех продуктов
Целевой программной основой публичных веб-компонентов, интернет-магазина и
клиентского CRM-контура Экосистемы являются совместимые программные продукты
семейства «1С-Битрикс» и «1С-Битрикс24». Выбор указанной программной основы
обусловлен необходимостью совместимости с существующей цифровой инфраструктурой
Заказчика, действующим интернет-магазином, накопленными данными и используемыми
интеграциями.
Электронный
каталог
Существующее решение на
платформе КАМИС
«Коллекция онлайн»
Конкретный состав программных продуктов, редакций и лицензий, количество
экземпляров, распределение компонентов между ними, а также необходимость
приобретения, продления или изменения действующих лицензий определяются
Подрядчиком по результатам обследования.
В рамках обследования Подрядчик обязан:

провести инвентаризацию имеющихся у Заказчика лицензий, экземпляров
программных продуктов, установленных модулей и условий их использования;
10

сопоставить возможности имеющихся лицензий с функциональными,
интеграционными, нагрузочными, эксплуатационными требованиями и
требованиями информационной безопасности настоящего ТЗ;

определить целевую лицензионную и архитектурную схему;

представить перечень используемых, приобретаемых и продлеваемых лицензий с
указанием редакций, количества, срока действия, владельца, назначения и
компонентов Экосистемы, для которых они необходимы;

обосновать необходимость использования нескольких экземпляров программных
продуктов либо размещения нескольких компонентов в одном экземпляре;

определить последствия прекращения обновлений или действия каждой лицензии
для работоспособности, безопасности и возможности сопровождения Экосистемы.
Результаты обследования фиксируются в архитектурном решении и лицензионной
схеме и подлежат утверждению Заказчиком до начала соответствующей разработки.
Выбранная лицензионная и архитектурная схема должна обеспечивать выполнение
полного объёма требований настоящего ТЗ, необходимую производительность,
информационную безопасность, возможность обновления, резервного копирования,
независимого сопровождения и дальнейшего развития Экосистемы.
Определение конкретных редакций и количества лицензий по результатам
обследования не является основанием для сокращения предусмотренного настоящим ТЗ
функционального объёма Работ, ухудшения характеристик Экосистемы или
возникновения необоснованной технологической зависимости компонентов друг от друга.
Учётная запись посетителя Экосистемы, клиентская запись CRM и корпоративная
учётная запись сотрудника являются различными сущностями независимо от того,
реализованы ли соответствующие функции в одном или нескольких программных
продуктах либо экземплярах. Совместное размещение компонентов не должно приводить
к использованию корпоративной учётной записи сотрудника или клиентской записи CRM
для непосредственной авторизации посетителя.
Стоимость приобретения и продления лицензий, необходимых для разработки,
испытаний, ввода Экосистемы в эксплуатацию и её работы в течение установленного
Контрактом периода, включается в цену Контракта, за исключением лицензий, прямо
указанных в ТЗ или приложениях к Контракту как предоставляемые Заказчиком.
Уточнение лицензионной схемы по результатам обследования само по себе не является
основанием для увеличения цены Контракта.
3.3. Обследование
При необходимости взаимодействия с уже используемыми системами Заказчика
допускается указание конкретных систем, сервисов и программных интерфейсов. Такое
указание применяется исключительно для обеспечения совместимости с действующими
цифровыми продуктами, учетными записями, доменами, корпоративным порталом,
билетным контуром, интернет-магазином, мобильным приложением, средствами
аналитики, почтовыми отправителями и инфраструктурой Заказчика.
Участник закупки вправе предложить эквивалентное решение для согласования с
Заказчиком, если оно обеспечивает все требования настоящего ТЗ, включая
11
совместимость, миграцию данных, информационную безопасность, приемку, гарантию и
отсутствие дополнительных расходов Заказчика на замену действующих систем, если
иное прямо не предусмотрено контрактом.
В начале Работ Подрядчик обязан обследовать существующие продукты, исходные
коды, инфраструктуру, учетные записи, интеграции, модели данных, документы,
лицензии, контрактные ограничения и технический долг. Результаты оформляются
отчетом об обследовании и не могут использоваться для исключения заранее
установленного объема Работ.
Если при обследовании выявлена объективная невозможность безопасной
доработки отдельного компонента, Подрядчик обязан предоставить доказательства,
варианты решения, оценку влияния и рекомендуемую архитектуру. Решение о способе
реализации принимает Заказчик в пределах ТЗ и Контракта.
3.4. Исходные материалы Заказчика









карта сайта и перечень цифровых сервисов;
утвержденные либо ранее согласованные дизайн-материалы;
брендбук и правила использования фирменного стиля;
концепция системы лояльности и игровых механик;
результаты аудита мобильного приложения и тестового стенда интернет-магазина;
доступная документация билетной системы, CRM, корпоративного портала, 1С и иных
интеграций;
исходный контент, имеющиеся переводы, изображения и сведения о правах на
материалы;
локальные нормативные акты и требования к обработке персональных данных;
доступы и учетные записи в объеме, необходимом для Работ.
4. Назначение, цели и ожидаемые результаты
4.1. Назначение Экосистемы
Экосистема предназначена для создания единого цифрового пространства Музея,
обеспечивающего доступ к театральному наследию, планирование и сопровождение
посещения, получение услуг, приобретение билетов и товаров, участие в образовательных
и игровых сценариях, взаимодействие с Музеем и продолжение культурного опыта после
очного посещения.
4.2. Цели создания Экосистемы








обеспечение доступного и достоверного публичного представления музейных
предметов, коллекций и истории театра;
формирование единого пользовательского опыта во всех цифровых продуктах Музея;
создание единого личного кабинета и идентификатора пользователя;
объединение билетных, торговых, коммуникационных сценариев и сценария
лояльности;
развитие семейной, детской, образовательной и межпоколенческой аудитории;
повышение доступности Музея для пользователей с особыми потребностями;
повышение доступности Музея для пользователей из регионов
формирование единой системы аналитики и управленческой отчетности;
12



повышение управляемости цифровых продуктов и сокращение ручного переноса
данных;
обеспечение безопасности, наблюдаемости, резервного копирования и восстановления;
устранение критической зависимости от конкретного подрядчика или закрытого
технологического решения.
4.3. Ожидаемые результаты
Область
Культурная миссия
Пользовательский
опыт
Посещение и
сервисы
Коммуникации
Управление
Аналитика
Эксплуатация
Передача
Ожидаемый результат
Коллекции и знания Музея представлены в цифровой среде
достоверно, доступно и содержательно.
Пользователь проходит сквозные сценарии без повторной
регистрации, потери контекста и несогласованных интерфейсов.
Доступны сведения о филиалах, доступности, событиях, билетах,
маршрутах и правилах посещения. Билеты, магазин и лояльность
работают как связанные части Экосистемы.
Обращения и сервисные сообщения фиксируются и
обрабатываются в согласованном клиентском контуре.
Сотрудники управляют контентом, правилами, пользователями и
отчетами в пределах ролей.
События пользователя и технические показатели доступны в
согласованной системе отчетности.
Экосистема имеет среды, мониторинг, журналы, резервные копии,
регламенты релизов и восстановления.
Исходники, права, учетные записи, документация и знания
переданы Заказчику.
4.4. Показатели достижения целей
Целевые значения установлены в разделе 14 настоящего ТЗ и не могут быть
заменены показателями объема трудозатрат. В состав показателей должны входить как
минимум:










успешность прохождения обязательных пользовательских сценариев;
доступность критических сервисов;
время загрузки и отклика;
доля ошибок интеграций;
доля успешных авторизаций и переходов к покупке;
полнота передачи данных о билетах, заказах и операциях лояльности;
соответствие требованиям доступности;
результаты восстановления из резервной копии;
отсутствие блокирующих и критических дефектов;
полнота переданных исходных материалов и документации.
5. Принципы создания Экосистемы
Принцип
Целостность
Единая
идентичность
Содержание
Все продукты проектируются как части единой Экосистемы, а не
как независимые сайты и приложения.
Пользователь имеет единый профиль, согласия и идентификатор
во всех поддерживаемых каналах.
13
Принцип
Достоверность
Доступность
Безопасность по
проекту
Владение
Заказчика
Открытые
интерфейсы
Наблюдаемость
Контроль по
результатам
Сопровождаемость
Содержание
Музейные и исторические сведения публикуются из
определенных источников и проходят содержательное
утверждение.
Критические сценарии доступны на разных устройствах и для
пользователей с особыми потребностями. Разработка ведется по
принципу «сначала мобильные».
Меры защиты учитываются на стадиях анализа, проектирования,
разработки, тестирования и эксплуатации.
Домены, репозитории, облачные проекты, аналитические ресурсы
и учетные записи создаются на стороне Заказчика или передаются
ему.
Интеграции документируются и версионируются; данные могут
быть выгружены в согласованных форматах.
Состояние сервисов и интеграций измеряется, а сбои
диагностируются по метрикам и журналам.
Четыре этапа предусматривают самостоятельные результаты, их
приемку и оплату. Контрольные точки, установленные в рамках
каждого этапа, предназначены для подтверждения хода
выполнения Работ. Завершение каждой контрольной точки
оформляется работающим промежуточным результатом,
комплектом актуальной документации и результатами проверки
по установленным сценариям. На третьем этапе осуществляется
проверка совместного функционирования всех компонентов
Экосистемы
Другая квалифицированная организация/подрядчик должна иметь
возможность развернуть и развивать систему по переданным
материалам.
6. Состав и границы Экосистемы
Компонент
Основной сайт
CMS
Единый
пользовательский
контур
Личный кабинет
Билетный контур
Интернет-магазин
Мобильное приложение
Назначение
Публичное представление Музея, событий, филиалов, услуг
и материалов.
Управление страницами, событиями, коллекциями,
переводами, метаданными и публикациями.
Регистрация, авторизация, идентификатор, профиль,
согласия, настройки и единый вход.
Билеты, заказы, бонусы, избранное, подписки, обращения,
достижения и цифровые материалы.
Переход к покупке, получение сведений о билете, QR,
статусы и события для CRM и лояльности.
Каталог, поиск, карточка товара, корзина, заказ, оплата,
доставка, личный кабинет и интеграция с 1С.
Мобильный доступ к контенту, билетам, лояльности,
маршрутам, аудио, игровым и AR-сценариям.
14
Компонент
Электронный каталог
Программа лояльности
Игровые механики
AR и аудиогиды
CRM и обращения
Аналитика
Эксплуатационный
контур
Сайт Фонда
Назначение
Самостоятельный компонент цифровой экосистемы и
интегрируется с остальными сервисами посредством
согласованных механизмов обмена данными.
Единый баланс, правила, уровни, достижения, награды,
промокоды и защита от злоупотреблений.
Задания, маршруты, коллекционирование, достижения и
межканальные события.
Дополненная реальность, мультимедийные материалы и
музейные маршруты.
Единый клиентский профиль, обращения, история
взаимодействий и коммуникации.
Продуктовые, коммуникационные, коммерческие и
технические события и отчеты.
Среды, автоматизация сборки, мониторинг, журналы,
резервирование и управление инцидентами.
Публичное представление деятельности Фонда с
сохранением действующего дизайна и пользовательского
поведения; управление содержанием через общую CMS.
6.1. Границы ответственности
Для каждого компонента в архитектурной документации определяется владелец,
источник достоверных данных, перечень функций, программные интерфейсы,
персональные данные, внешние зависимости, порядок эксплуатации и ответственность
сторон.
Подрядчик отвечает за разработанные им интеграционные компоненты,
корректную обработку недоступности внешней системы, журналирование,
пользовательские сообщения и совместное тестирование.
6.2. Единый пользовательский контур
Единый пользовательский контур обеспечивает идентификацию, аутентификацию,
подтверждение контактов, управление профилем, согласиями, настройками и единым
экосистемным идентификатором посетителя.
Учётная запись посетителя и клиентская запись CRM являются различными
связанными сущностями. Клиентская запись CRM используется для учёта
взаимодействий, обращений и предусмотренных событий и связывается с учётной
записью посетителя по экосистемному идентификатору. Клиент CRM, контакт CRM или
пользователь корпоративного портала не должен использоваться в качестве учётной
записи для авторизации посетителя.
Корпоративные учётные записи сотрудников Музея должны быть отделены от
пользовательских учётных записей посетителей.
Единая модель пользователей и данных не означает обязательного хранения всех
сведений в одной физической базе данных. Допускается использование нескольких
экземпляров программных продуктов при наличии единой модели идентификаторов,
документированных программных интерфейсов, правил синхронизации и определённых
источников достоверных данных.
15
Основной сайт, интернет-магазин и мобильное приложение не должны создавать
несвязанные учётные записи посетителя и отдельные балансы программы лояльности.
Повторная авторизация допускается только при документированном ограничении
внешней системы и должна быть согласована Заказчиком в архитектурном решении.
6.3. Функциональная матрица объема Работ
Обязательный объем Работ определяется настоящим Техническим заданием и
функциональной матрицей Экосистемы, приведенной в Приложении № 6 к настоящему
ТЗ. Для каждой функции в функциональной матрице указываются:




уникальный идентификатор;
компонент Экосистемы;
пользовательская, административная или эксплуатационная роль;
состав обязательной реализации к моменту ввода Экосистемы в промышленную
эксплуатацию;
 настраиваемые параметры и предусмотренные способы дальнейшего расширения;
 требования к архитектурной готовности;
 контрольная точка календарного плана;
 зависимости и ограничения;
 результат Работ;
 критерий приемки.
Функциональная матрица, приведённая в Приложении № 6, устанавливает
минимальный обязательный объём Работ.
В рамках этапа обследования и проектирования Подрядчик обязан дополнить и
уточнить функциональную матрицу для каждой функции, указанной в Приложении № 6,
указав роли пользователей и каналы реализации, контрольную точку и подтверждаемый
результат, зависимости и ограничения, а также идентификаторы связанных сквозных
сценариев в случае несоответствия после обследования.
Дополненная функциональная матрица согласовывается с Заказчиком. Её
уточнение не может приводить к исключению обязательных функций, уменьшению
установленного объёма, ухудшению критериев приёмки, переносу функций за пределы
Контракта или изменению условий Контракта без их оформления в установленном
порядке.
Частные технические задания, спецификации и архитектурные документы могут
детализировать требования функциональной матрицы, но не могут:





исключать обязательные функции;
переносить обязательные функции за пределы Контракта;
заменять реализацию функции демонстрационным прототипом;
уменьшать установленный объем наполнения, интеграций или сценариев;
исключать обязательную функцию из итогового результата либо переносить ее за
пределы Контракта без письменного изменения Контракта;
В случае изменения Контракта ввиду изменения технологических особенностей
цифрового продукта, такие изменения не могут влечь изменения цены Контракта. Цена
контракта не подлежит изменению в сторону увеличения;
16
Если дальнейшее расширение функции влияет на идентификацию пользователей,
модель данных, согласия, события, программные интерфейсы или архитектуру, в составе
Работ должна быть обеспечена соответствующая архитектурная готовность.
7. Пользователи, роли и права доступа
Роль
Неавторизованный
пользователь
Зарегистрированный
пользователь
Родитель или иной
совершеннолетний
пользователь,
управляющий
связанным детским
профилем
Исследователь
Контент-редактор
Публикующий редактор
Оператор обращений
Маркетолог/аналитик
Администратор
продукта
Технический
администратор
Специалист по
безопасности
Основные полномочия
Просмотр публичной информации, поиск, планирование
визита, переход к покупке.
Профиль, согласия, избранное, билеты, заказы, обращения и
лояльность.
Семейные сценарии, детские программы и связанные
профили в предусмотренном объеме.
Доступ к опубликованным научным данным и специальным
материалам в пределах правил Музея.
Создание и редактирование контента без права публикации,
если роли разделены.
Проверка и публикация контента, управление версиями.
Просмотр и обработка обращений в клиентском контуре.
Настройка согласованных кампаний, сегментов и отчетов без
избыточного доступа к данным.
Настройка справочников, ролей, правил и интеграций в
пределах полномочий.
Эксплуатация, диагностика, релизы и восстановление.
Контроль журналов, прав, уязвимостей и событий
безопасности.
7.1. Требования к модели доступа







принцип минимально необходимых полномочий;
разделение функций редактирования и публикации для критичного контента;
отдельные административные учетные записи;
многофакторная аутентификация для привилегированных ролей;
регистрация входов, изменений прав, публикаций, выгрузок и критичных операций;
периодическая проверка актуальности прав;
оперативное прекращение доступа уволенных сотрудников и завершивших работу
подрядчиков.
7.2. Матрица ролей и прав доступа
Подрядчик обязан разработать, согласовать с Заказчиком и реализовать матрицу
ролей и прав доступа для всех административных и внутренних компонентов Экосистемы.
Минимальный состав ролей и полномочий устанавливается Приложением № 7 к
настоящему ТЗ. Матрица уточняется по результатам обследования без исключения
предусмотренных ролей, ограничений и требований к аудиту.
Для каждой роли должны быть определены права на:
17











просмотр;
создание;
изменение;
согласование;
публикацию;
архивирование;
удаление;
экспорт;
изменение справочников и настроек;
просмотр журналов;
управление пользователями и правами.
Совмещение ролей допускается только при отсутствии недопустимого конфликта
полномочий. Операции публикации критичного контента, изменения правил лояльности,
ручной корректировки бонусов, экспорта персональных данных и назначения
административных прав должны журналироваться.
8. Обязательные сквозные сценарии
Обязательные сквозные сценарии охватывают пользовательские,
административные, интеграционные и эксплуатационные процессы Экосистемы. Все
указанные сценарии подлежат реализации и приёмочным испытаниям.
Обозначения критичности:



К — критический сценарий;
О — обязательный некритический сценарий;
К/О — составной сценарий, критичность отдельных веток которого устанавливается
настоящим ТЗ и паспортом сценария.
Отсутствие статуса «К» не означает возможности исключения сценария из состава
Работ или приёмки.
Код
Критичн
ость
Роли и каналы
С-01
К
Посетитель; сайт,
приложение
С-02
О
Посетитель; сайт,
приложение
С-03
Посетитель; сайт,
К приложение,
билетная система
Сценарий и проверяемый результат
Пользователь находит филиал, часы работы,
правила посещения, сведения о
доступности, событие и маршрут.
Отображаются актуальные данные из
определённых источников.
Пользователь выполняет поиск, применяет
календарь, фильтры и сортировку,
сбрасывает условия и открывает найденный
объект. Обработаны пустая выдача и
ошибка поиска.
Пользователь переходит к покупке с
сохранением контекста события. Результат
оплаты и выпуска билета определяется
однозначно, повторная операция не создаёт
дубль. Обрабатываются отказ, тайм-аут,
неопределённый статус, отмена и возврат
при наличии соответствующего API.
18
Код
Критичн
ость
Роли и каналы
Пользователь; ЛК,
приложение
С-04
К
С-05
Пользователь; сайт,
К ЛК, магазин,
приложение
С-06
К
Пользователь; ЛК,
приложение
С-07
О
Пользователь; ЛК,
приложение
С-08
Покупатель;
магазин, ЛК, 1С,
К
платёжный и
кассовый контуры
С-09
Участник
программы
О лояльности; сайт,
магазин, ЛК,
приложение
С-10
О
Пользователь;
приложение, ЛК
С-11
О
Пользователь;
приложение
Сценарий и проверяемый результат
Активный QR-билет доступен
пользователю, в том числе в
предусмотренном офлайн-режиме. Статусы
активного, использованного, отменённого и
возвращённого билета отображаются без
доступа к чужим данным.
Проверяется полный цикл доступа:
регистрация, подтверждение контакта, вход,
повторный и истёкший код, восстановление
доступа, изменение подтверждённого
контакта, завершение сеанса и защита от
перебора.
Пользователь просматривает и изменяет
профиль, управляет согласиями и
коммуникационными предпочтениями,
получает доступ к истории согласий,
отзывает согласие и направляет
применимые запросы субъекта
персональных данных. Изменения
распространяются на связанные системы.
Отображаются связанные с единым
профилем билеты, заказы, бонусы,
обращения, избранное и цифровые
материалы. Проверяются полнота,
актуальность, пустые состояния и
отсутствие чужих данных.
Проверяется жизненный цикл заказа:
корзина, цена и остаток, доставка, оплата,
подтверждение, чек, статус, повтор заказа,
отмена и возврат. Повторный запрос не
создаёт повторную оплату или заказ.
Начисление, списание, отмена и иная
операция отражаются один раз в едином
балансе и истории. Проверяются повтор
события, срок действия, возврат покупки и
синхронизация каналов.
Пользователь получает задание, выполняет
условие, видит прогресс и получает
достижение или награду. Повторное
событие не создаёт повторное прохождение
или начисление.
Пользователь запускает маршрут или ARсценарий, предоставляет либо отклоняет
разрешения, получает связанный контент и
доступную альтернативу. Обрабатываются
слабая сеть и неподдерживаемое
устройство.
19
Код
Критичн
ость
Роли и каналы
Пользователь;
приложение, сайт
С-12
О
С-13
Пользователь и
оператор
О обращений; сайт,
ЛК, приложение,
CRM
С-14
Пользователь и
К/О администратор;
email, SMS, push, ЛК
С-15
Автор, переводчик,
К публикующий
редактор; CMS
С-16
К
Технический
администратор
С-17
К
Технический
администратор
С-18
К
Технический
администратор
С-19
Покупатель без
учётной записи;
К
билетный контур,
магазин, CRM, ЛК
Сценарий и проверяемый результат
Пользователь находит и воспроизводит
аудиоматериал, управляет
воспроизведением и возобновляет его с
сохранённой позиции. Проверяются потеря
сети и доступная текстовая альтернатива.
Обращение создаётся один раз, получает
номер, направляется ответственному,
обрабатывается оператором, меняет статус и
отображается пользователю. Проверяются
ответ, уточнение, закрытие, повторное
открытие и недоступность CRM.
Проверяются формирование, отправка и
результат доставки сервисных и
маркетинговых уведомлений, языковой
шаблон, ссылка на нужный объект,
повторная доставка, защита от дублей и
управление предпочтениями. Обязательные
сервисные сообщения являются
критической веткой.
Проверяется создание, валидация,
предварительный просмотр, перевод,
публикация, отложенная публикация,
снятие с публикации и восстановление
версии. Права, сроки использования
материалов и действия сотрудников
журналируются.
Искусственно вызванный отказ
критического сценария обнаруживается
мониторингом, получает идентификатор,
отображается на панели и вызывает
оповещение и эскалацию.
Версия собирается из репозитория,
проходит тестовую и предпромышленную
среды, выпускается в промышленную среду,
проходит smoke-тест и может быть откачена
вместе с совместимыми изменениями
данных.
Данные и сервис восстанавливаются из
фактической резервной копии.
Подтверждаются целостность, RPO, RTO и
работоспособность контрольных сценариев.
После покупки создаётся либо находится
технический профиль, покупка
привязывается без дубля и остаётся
действительной без активации ЛК. После
подтверждения контакта пользователь
получает доступ к своим покупкам без
автоматического маркетингового согласия.
20
Код
С-20
С-21
С-22
С-23
С-24
С-25
С-26
С-27
Критичн
ость
Роли и каналы
Сценарий и проверяемый результат
Пользователь переходит между продуктами
без создания новой учётной записи и без
Пользователь; сайт,
необоснованной повторной авторизации.
К ЛК, магазин,
Сохраняются единый идентификатор, язык,
приложение
целевой объект и предусмотренное
состояние операции.
Проверяются первый запуск, отказ от push,
камеры и геолокации, слабая и
отсутствующая сеть, возврат из фонового
Пользователь;
режима, офлайн-доступ к QR и заранее
К/О мобильный сайт,
загруженным материалам, а также
приложение
неподдерживаемое устройство.
Критичность наследуется от проверяемого
сценария.
Перевод создаётся отдельно от оригинала,
проходит проверку и публикацию.
Переводчик,
Проверяются статус перевода, неполный
О редактор; CMS, сайт,
перевод, правила замещения, адреса,
приложение
метаданные и отсутствие изменения
оригинала переводчиком.
Проверяются настройка и публикация
правила, даты и ограничения,
Менеджер и
резервирование, выдача и отмена награды, а
К/О администратор
также ручная корректировка с обязательным
лояльности
основанием. Денежные и балансовые
операции являются критическими ветками.
По задокументированным источникам
воспроизводимо формируется отчёт или
Аналитик,
О
разрешённый сегмент. Проверяются
маркетолог
формула, период, фильтры, возвраты,
отмены, дубли, права доступа и экспорт.
Проверяются создание и прекращение
Администратор
доступа, назначение роли, MFA, запрет
доступа, специалист
К
повышения собственных полномочий, отзыв
по безопасности,
доступа Подрядчика и защищённый
аудитор
просмотр журналов.
Сохраняются структура, материалы,
навигация, визуальная идентичность,
Посетитель и
действующие сценарии и адреса сайта
О редактор; сайт
Фонда. Редактор изменяет и публикует
Фонда, CMS
содержимое через общую CMS без
изменения кода.
Пользователь находит и открывает
Пользователь
опубликованный музейный объект, видит
электронного
источник, актуальность и разрешённую
О
каталога; сайт,
цифровую копию. Проверяются устойчивый
электронный каталог идентификатор, ограничения прав и
недоступность внешнего источника.
21
Для каждого сценария Подрядчик разрабатывает паспорт в составе программы и
методики испытаний. Паспорт не может исключать предусмотренные настоящим ТЗ роли,
каналы, отрицательные ветки, интеграции, состояния интерфейса и доказательства.
Один сценарий может состоять из нескольких тестовых случаев. Сценарий
считается пройденным только после успешного выполнения всех применимых
обязательных тестовых случаев во всех предусмотренных каналах. Статусы «не
проверено», «не удалось воспроизвести», «не готова внешняя система» и «будет
проверено после запуска» не означают успешного прохождения.
Минимальный состав приёмочных проверок и доказательств по каждому
сквозному сценарию устанавливается Приложением № 1 к настоящему ТЗ.
9. Функциональные требования
Функциональные требования настоящего ТЗ реализуются поэтапно в соответствии
с разделом 17 и функциональной матрицей Приложения № 6.
Этап 1 включает русскоязычный основной сайт Музея: главную страницу, афишу и
страницы событий, новости, страницы всех филиалов, необходимые справочные сведения,
билетный контур на базе действующего решения, систему управления содержанием и
применимые официальные и юридические страницы по пункту 9.1.4. Обеспечиваются
редизайн действующего интернет-магазина, общие визуальные элементы и
навигационные переходы между сайтом и магазином, сохранение действующих торговых
сценариев и сервисных уведомлений.
На этапе 1 сохраняются действующие авторизация и личный кабинет интернетмагазина. Отдельная новая система учётных записей основного сайта не создаётся. Поиск
по основному сайту и английские версии пользовательских интерфейсов вводятся на этапе
2. Действующий поиск интернет-магазина сохраняется.
На этапе 2 вводятся полный основной сайт, сайт Фонда, витрина коллекции, единая
авторизация SSO, единый личный кабинет, клиентский CRM-контур, программа
лояльности, предусмотренные интеграции и опубликованные мобильные приложения.
Обеспечиваются русская и английская локализации пользовательских интерфейсов
продуктов, вводимых в составе этапа.
На этапе 1 выполняются сбор базовых аналитических событий опубликованных
продуктов и сохранение существующих торговых событий. На этапе 2 обеспечивается их
включение в единый аналитический контур.
Этапность определяет срок исполнения требований и не уменьшает полный
обязательный объём ТЗ. В публичном интерфейсе не допускаются неработающие
разделы, элементы поиска и переключения языка либо ссылки на ещё не введённые
функции. Последующее развитие осуществляется с сохранением работоспособности
опубликованных продуктов.
9.1. Основной сайт

главная страница с доступом к ключевым сервисам, событиям, филиалам, коллекциям,
новостям и магазину;
22









разделы «О музее», «Новости», «Филиалы и музейно-театральный квартал»,
«Выставки и события», «Коллекции», «Посетителям», «Бахрушинский детям»,
«Поддержать музей», «Контакты»;
афиша с календарем, фильтрами по месту, типу, аудитории, доступности и иным
согласованным признакам;
карточка события с описанием, датой, местом, возрастной маркировкой, описанием
доступности, маршрутом, формой покупки билета;
поиск по типам контента, поддерживающий как минимум морфологию русского
языка, опечатки и релевантную выдачу либо эквивалентный согласованный уровень;
карты, маршруты, сведения о доступности и сервисах филиалов;
формы обращений, подписок, волонтерства и партнерских инициатив;
сквозные русская и английская версии пользовательских интерфейсов; архитектура
должна обеспечивать добавление последующих языков без переработки бизнес-логики
и программных компонентов;
технические страницы, карта сайта, юридические страницы и юридически значимые
интерфейсные тексты, подготовленные, согласованные и размещённые в соответствии
с пунктом 15.7 настоящего ТЗ;
корректная индексация поисковыми системами, структурированные данные,
метаданные и управление перенаправлениями.
9.1.1 Дизайн-макеты основного сайта
В рамках работ разрабатываются дизайн-макеты всех страниц публичного сайта по
согласованной карте сайта, главная — на основе ранее утвержденного макета. Макеты
выполняются в единой дизайн-концепции экосистемы и согласовываются с Заказчиком до
начала верстки.
В процессе разработки дизайн-макетов Заказчик имеет право вносить
обоснованные замечания, корректировки и предложения по улучшению визуального и
пользовательского опыта в рамках утвержденной карты сайта и структуры экосистемы.
Все правки согласовываются сторонами. Подрядчик обязан учитывать замечания
Заказчика, если они не выходят за пределы функционального объема, определенного
настоящим ТЗ, и не требуют изменения архитектуры или расширения состава
страниц/экранов.
9.1.1.1 Состав страниц для создания дизайн-макетов в рамках этапа подготовки









Главная
О музее (включая блок истории)
Филиалы и музейно-театральный квартал: музейно-театральный квартал (обзор);
страница филиала; страница здания
Выставки и события: афиша (+ календарь); страница мероприятия; онлайн-выставки
Коллекции: список коллекций; страница коллекции
Посетителям: билеты и льготы; карты лояльности; «Добродень»; доступный музей
Бахрушинский детям: детский центр; мастер-классы; экскурсии
Пресс-центр: новости и СМИ; страница новости
Поддержать музей: стать волонтёром; попечительский совет; корпоративные
программы; фонд развития; сотрудничество
23

Личный кабинет: авторизация/регистрация; профиль пользователя; история покупок;
подписки; избранные мероприятия (требования к Единому личному кабинету указаны
в п. 9.4 настоящего ТЗ)
 Контакты
 Результаты поиска
Дополнительно в составе дизайна: дизайн-система / набор пользовательских
интерфейсов (токены, мастер-компоненты, состояния); адаптивные версии (версия для
компьютеров, планшетов, мобильных устройств); макеты русской и английской
локализации интерфейсных состояний.
Формат результата: редактируемые исходные макеты и экспорт в PDF; бумажные
копии предоставляются по запросу Заказчика. Приведенный состав страниц относится к
обязательному объему Работ.
Требования к качеству дизайн-макетов (дизайн-система, токены, макеты и
расположение, состояния, адаптивность макетов) — единые для сайта, магазина и
приложения.
9.1.2 Верстка и программирование основного сайта
В рамках Работ выполняется вёрстка и программная реализация утверждённых
дизайн-макетов на CMS: используется утверждённый дизайн главной страницы, а также
макеты, разработанные в рамках этапа создания дизайн-макетов этапа.
В пункте 9.1.3 детализированы функциональные требования к разделам с
нетривиальной логикой (фильтры, календарь, слайдеры, интеграции) и к сквозным
сервисам. Остальные страницы — «О музее», «Посетителям» (билеты и льготы, карты
лояльности, «Добродень», доступный музей), «Бахрушинский детям», «Поддержать
музей», «Контакты», «Пресс-центр / СМИ», онлайн-выставки, служебные — реализуются
как тексто-графические страницы на основе шаблона и набора виджетов из дизайнсистемы.
9.1.3 Перечень разрабатываемых разделов и функций
1. Шапка (глобальная, на всех страницах): верхняя строка экосистемы — ссылки
«Магазин», «Театральная энциклопедия», «Медиа»; поиск, личный кабинет,
переключатель языка (RU/EN); основная навигация — меню, «Афиша», логотип, «Купить
билет».
2. Главная страница (на основе утверждённого макета и согласованной структуры;
блоки в порядке размещения):


Hero — полноэкранный динамический коллаж событий: несколько образов, каждый
привязан к событию/выставке; образы и заголовок сменяются; клик по образу —
переход на страницу соответствующего события (обычный переход, не
одностраничное приложение — для корректной SEO-индексации). Управление
контентом через CMS.
Афиша — заголовок, вкладки (Все / Выставки / Экскурсии / Спектакли),
ограниченный список карточек, «Смотреть все» → страница афиши. Карточка: дата,
площадка/филиал, изображение, тип события и возрастная маркировка, название. На
главной без цен и кнопки «Купить» (покупка — на странице события).
24

Коллекции — текст-анонс фондов и кнопка «Узнать больше» → внутренняя страница
«Коллекция»; декоративное оформление (параллакс). Интерактивный просмотр
экспонатов — на внутренней странице, не на главной.
 Музейно-театральный квартал — карточка объекта (адрес, бейджи
доступности/удобств, фото, «Узнать больше»), слайдер объектов с ручной пагинацией,
переключатель «Филиалы» (раскрывает список). Без автоматической прокрутки.
 Новости — ограниченный список карточек (изображение, заголовок, дата), подписка
на рассылку, «Смотреть все» → раздел новостей.
 Промо-блок — редактируемый через CMS слайдер промо-материалов (изображение,
заголовок, описание, кнопка).
 Интернет-магазин — витрина с вкладками по категориям (Все / Одежда / Аксессуары/
Сувениры), карточка (изображение, категория, название, цена), «Смотреть все» →
интернет-магазин.
3. Раздел «Афиша» — страница со списком мероприятий; календарь с выбором даты;
фильтры по филиалу/зданию и по типу события (выставки, экскурсии, спектакли);
сортировка по дате и участию в «Пушкинской карте»; индивидуальная страница
мероприятия (иллюстрация, название, описание, возрастная маркировка, кнопка «Купить
билет», карта с маршрутом); интеграция с билетной системой (существующий виджет).
4. Раздел «Коллекции» — внутренняя страница (на неё ведёт блок коллекции с главной):
выборочная часть коллекции музея, описание, карточки экспонатов (фото, название,
краткое описание), при клике — карточка с подробным описанием.
5. Раздел «Музейно-театральный квартал и филиалы» — страница с фотографиями
зданий музейно-театрального квартала и списком филиалов; при клике на объект —
индивидуальная страница (баннер, краткое описание, события/экскурсии/экспонаты,
адрес, карта с маршрутом).
6. Раздел «Новости» — страница со списком новостей (фильтр по дате/популярности),
подписка на рассылку; карточка новости (заголовок, дата, иллюстрация, краткое
описание), при клике — полный текст.
7. Поиск по сайту — поисковая строка в шапке (поиск по основному сайту); фильтрация
результатов по типам контента.
8. Подвал — навигация, часы работы, контакты, адрес, подписка на новости, социальные
сети/мессенджеры, логотипы (Минкультуры РФ, Культура.РФ), правовые ссылки.
9.1.4. Размещение обязательных правовых, технических и официальных страниц
В составе Экосистемы должны быть реализованы следующие страницы, доступные
не более чем в один клик из подвала (футера) на всех страницах основного сайта,
интернет-магазина, а также из раздела «Настройки» или «О приложении» в мобильном
приложении, уточненные списки ссылок для каждого сервиса и продукта уточняются в
ЧТЗ:





карта сайта;
политика обработки персональных данных;
согласия на обработку данных (включая версии согласий);
сведения об организации (реквизиты, структура, контакты);
правовая информация (пользовательское соглашение, оферта, порядок возврата
билетов и товаров);
25

официальные документы Музея (устав, положения, приказы, регулирующие
деятельность);
 годовые отчёты о деятельности Музея (в формате, доступном для скачивания);
 информация о противодействии коррупции (включая контакты ответственных лиц и
порядок сообщения о коррупционных проявлениях).
Названия пунктов меню в подвале и в приложении должны быть единообразными
и соответствовать внутренней номенклатуре Заказчика. Ссылки на указанные страницы
должны вести на актуальные версии документов, размещённые в CMS, и не требовать для
просмотра авторизации.
9.2. Система управления контентом









управление типами контента, страницами, блоками, меню, формами, событиями,
коллекциями и справочниками;
черновики, предварительный просмотр, отложенная публикация, версии и
восстановление предыдущей версии;
раздельные роли автора, редактора и публикующего сотрудника;
управление языковыми версиями, переводами интерфейсов и контента, контроль
полноты и статуса перевода;
управление SEO-метаданными, адресами страниц и перенаправлениями;
валидация обязательных полей, форматов изображений и прав на материалы;
журнал действий и публикаций;
массовый импорт и экспорт в документированном формате;
редактирование без необходимости изменения программного кода для типовых
операций.
9.3. Регистрация, авторизация и профиль














регистрация и вход по телефону и/или электронной почте с подтверждением;
настройка обязательности заполнения полей после регистрации;
зависимость заполнения профиля и доступные действия;
поддержка входа без постоянного пароля; допустимы одноразовый код, ссылка или
иной безопасный механизм;
единый идентификатор пользователя и единый сеанс для согласованных продуктов;
подтверждение и изменение контактов;
защита от перебора, злоупотреблений и автоматизированной регистрации;
восстановление доступа;
профиль: ФИО, контакты, дата рождения при наличии правового основания,
предпочтения, доступность и иные согласованные сведения;
история согласий с версией текста, датой, временем, источником и способом
подтверждения;
управление подписками и каналами уведомлений;
удаление или блокирование учетной записи в предусмотренном правовыми
документами порядке.
покупка билета или товара не должна требовать обязательной предварительной
регистрации или активации личного кабинета, если иное не уточнено в ЧТЗ после
обследования;
при гостевой покупке создаётся либо определяется технический идентификатор
клиента и связанная клиентская запись CRM, но не активированная учётная запись
посетителя;для получения доступа к личному кабинету пользователь подтверждает
26






адрес электронной почты или номер телефона и самостоятельно активирует учетную
запись;
если связанная клиентская запись уже существует, покупка привязывается к ней без
создания дубля;
пароль в открытом виде не создается и не направляется пользователю; покупка, билет,
заказ, и кассовый чек сохраняют действительность независимо от активации личного
кабинета;
после активации к профилю привязываются относящиеся к нему покупки, билеты,
заказы и начисления программы лояльности;
автоматическое создание технического профиля не означает согласия на рекламу или
маркетинговые рассылки;
объединение возможных дублей выполняется только по подтвержденным
идентификаторам, с журналированием оснований, исходных записей и результата;
система должна исключать повторное создание профиля и повторное начисление при
повторной доставке интеграционного события.
9.4. Единый личный кабинет








активные и прошедшие билеты, QR-коды и доступные статусы;
история заказов интернет-магазина и детальная информация о заказе;
единый баланс, история операций, уровни, достижения и доступные награды
программы лояльности;
избранные события, товары, материалы и маршруты;
подписки, сервисные уведомления и настройки коммуникаций;
обращения и доступные статусы их обработки;
цифровые материалы, доступные после покупки или посещения;
создание и управление связанными детскими профилями, привязка к ним детских
билетов, маршрутов, заданий и достижений в объёме пункта 9.4.1;выгрузка
пользовательских данных в применимом объеме.
9.4.1. Семейные и детские профили
Авторизованный совершеннолетний пользователь должен иметь возможность
создавать, просматривать, изменять и удалять связанные детские профили в пределах
своего личного кабинета.
Детский профиль:

не является самостоятельной учётной записью и не имеет собственных средств
аутентификации;
 управляется создавшим его совершеннолетним пользователем;
 содержит минимально необходимый состав данных;
 может использоваться для привязки детских билетов, прохождения маршрутов,
игровых достижений и иных предусмотренных ТЗ детских сценариев;
 не получает маркетинговых согласий автоматически;
 не может самостоятельно совершать оплату, публиковать сведения или изменять
согласия;
 не должен быть публично доступен другим пользователям.
Создание, изменение, привязка и удаление детского профиля журналируются.
Состав данных, возрастные категории, правила удаления и интерфейс управления
27
уточняются в ЧТЗ и прототипах не позднее КТ-2 без уменьшения указанного
обязательного результата.
Совместное управление детским профилем несколькими взрослыми, передача профиля
между семейными группами и единый семейный баланс программы лояльности в объём
настоящего Контракта не входят.
9.5. Билетный контур









встраивание виджета или интеграция по программному интерфейсу с сохранением
контекста события;
получение сведений о результате покупки и статусах билетов в пределах
возможностей внешней системы;
сопоставление билета с единым пользователем;
отображение QR-билета и истории;
передача событий покупки, возврата и посещения в CRM, аналитику и лояльность при
наличии правового и технического основания;
идемпотентная обработка повторных уведомлений;
понятные сообщения пользователю при отказе внешней системы;
журналирование запросов без раскрытия чувствительных данных;
совместные интеграционные испытания.
9.6. Интернет-магазин
Интернет-магазин является самостоятельным продуктом Экосистемы. В состав
Работ входят редизайн интернет-магазина, доработка изменяемых Подрядчиком
компонентов, интеграция с единым пользовательским контуром, личным кабинетом,
программой лояльности, CRM и аналитикой, а также сохранение работоспособности
существующего торгового контура в части, затрагиваемой Работами.
В состав Работ не входят замена, развитие и сопровождение существующей
внутренней логики учётной системы 1С, эквайринга, контрольно-кассовой техники,
оператора фискальных данных и иных действующих компонентов торгового контура, за
исключением изменений, прямо предусмотренных настоящим ТЗ для их интеграции с
Экосистемой.
Если вследствие изменений, настройки, миграции или развёртывания,
выполненных Подрядчиком, нарушена ранее существовавшая работоспособность
интернет-магазина, обмена с 1С, оплаты, возвратов, фискализации или передачи чеков,
Подрядчик обязан за свой счёт восстановить нарушенную работоспособность и устранить
причину нарушения.
До начала изменений Подрядчик совместно с Заказчиком фиксирует исходное
состояние предусмотренных ТЗ сценариев интернет-магазина, обмена с 1С, оплаты,
возвратов и фискализации. Результат оформляется протоколом исходного состояния.
В состав обследования входит:




главная страница магазина, каталог, категории, поиск, фильтры, сортировка и
пагинация;
карточка товара, варианты, остатки, цена, изображения, характеристики,
рекомендации и сведения о доставке;
корзина, промокоды, бонусы, выбор доставки, оплата и подтверждение заказа;
личный кабинет магазина как часть единого личного кабинета;
28




история и детали заказов, повтор заказа, избранное, адреса доставки;
единые шапка, подвал, дизайн-система и авторизация;
начисление и списание бонусов по единым правилам;
интеграция с 1С по каталогу, ценам, остаткам, заказам, статусам и иным
согласованным данным;
 обработка возвратов в пределах бизнес-процесса и действующей учетной системы;
 события аналитики и CRM;
 миграция действующего каталога и контента в установленном объеме.
Включая интеграционные требования:
 единые ссылки и переходы между сайтом, личным кабинетом, приложением при
наличии и магазином;
 единые элементы дизайн-системы в согласованных точках входа;
 отображение истории заказов магазина;
 передача согласованных событий магазина в CRM/аналитику при наличии API и
правового основания;
 участие заказов магазина в программе лояльности только при наличии согласованного
API и правил лояльности.
На этапе 1 выполняется приведение действующего интернет-магазина к единому
визуальному стилю: общие шапка и подвал, типографика, цветовая система и
навигационные переходы между сайтом и магазином, с сохранением действующих
торговых сценариев, оплаты, фискализации и обмена с учётной системой. Редизайн
экранов по пункту 9.6.1.1 на основе карты пути покупателя и встраивание сквозных
сервисов выполняются на этапе 2. Сохраняются существующие учётные записи и история
заказов.
Требования к общему SSO, единому личному кабинету, CRM и программе
лояльности реализуются к моменту завершения этапа 2. Переход выполняется с проверкой
связывания пользовательских профилей, сохранности данных и отсутствия дублирования
операций.
К завершению этапа 2 Подрядчик обеспечивает миграцию сведений о покупках
билетов и заказах интернет-магазина, совершённых начиная с публичного запуска этапа 1,
и их связывание с единым профилем посетителя. Пользователь получает доступ к
соответствующим покупкам после подтверждения принадлежащего ему контактного
идентификатора и безопасного сопоставления записей.
Миграция включает первоначальную загрузку, перенос изменений за переходный
период и итоговую сверку. Обеспечиваются сохранность идентификаторов, состава
покупок, сумм и статусов, отсутствие дублей, сохранение действительности билетов и
заказов и защита от доступа к чужим данным. Состав переносимых данных и порядок
сопоставления фиксируются в ЧТЗ и плане миграции без исключения указанного
обязательного результата.
9.6.1 Редизайн и доработка интернет-магазина
Интернет-магазин уже реализован на 1С-Битрикс, в рамках работ выполняются его
редизайн под единую дизайн-систему экосистемы и встраивание сквозных сервисов
(единый личный кабинет, программа лояльности и другие). Состав работ:
29
1. Редизайн всех страниц интернет-магазина — приведение к единой визуальной
концепции экосистемы (единые шапка и подвал, типографика, компоненты, состояния),
проверка адаптивности и доступности, основой редизайна служит карта пути покупателя
(CJM), разрабатываемая на этапе дизайна.
2. Интеграция с единым личным кабинетом — авторизация через общую систему
единого профиля. Сервис авторизации в интернет-магазине не должен дублироваться.
3. Интеграция с программой лояльности — начисление и списание бонусов за покупки,
отображение баланса и истории в корзине и при оформлении заказа.
4. Подключение интернет-магазина к сервисам интернационализации — перевод
интерфейса на английский язык, подключение к общей системе переводов.
5. Обновление каталога — настройка категорий, фильтров и сортировки под
обновленный дизайн.
6. Интеграция с основным сайтом — единые шапка и подвал, мега-меню каталога,
сквозные переходы между сайтом и магазином без повторной авторизации.
Итоговый контент (тексты, фотографии товаров) предоставляет Заказчик. Состав
миграции и первичного наполнения определяется Приложением № 11 и уточняется по
результатам обследования без превышения объема действующего каталога магазина на
дату заключения Контракта.
9.6.1.1 Перечень экранов под редизайн в рамках этапа подготовки









Витрина: главная магазина.
Каталог: каталог (корень); листинг категории (фильтры в боковой панели — sidebar,
на мобильных — в выдвижной панели, сортировка, пагинация, вид «плитка/список»);
карточка товара.
Покупка: корзина; оформление заказа (многошаговое оформление — checkout:
контакты, доставка, оплата, сводка); подтверждение заказа («спасибо»).
Поиск: результаты поиска (+ пустое состояние).
Личный кабинет магазина (на базе единого ЛК): сводная страница (дашборд);
заказы (список); заказ (детальный, повтор заказа); избранное; профили и адреса
доставки.
Промо: акции (список); акция (детальная).
Контент: контентный шаблон (1 шаблон → 6 страниц: «Покупателям», «Доставка и
оплата», «Возврат товара», «О магазине», «Правовая информация», FAQ); контакты.
Служебные: 404 и заглушки.
Сквозные элементы: единые шапка и подвал, мега-меню каталога, выдвижная панель
фильтров, модальные окна (быстрый просмотр, «добавлено в корзину»), превью
корзины.
9.7 Сайт Фонда
Подрядчик должен перенести действующий сайт Фонда развития Бахрушинского
музея под управление общей CMS Экосистемы с сохранением его визуальной
идентичности, информационной структуры, содержания и действующих
пользовательских сценариев.
Подрядчик должен воспроизвести существующий дизайн и пользовательское
поведение сайта средствами общей CMS выбранной при обследовании.
30
В рамках работ Подрядчик обязан:








сохранить визуальную концепцию сайта Фонда, включая композицию страниц,
цветовую палитру, типографику, графические элементы, принципы размещения
изображений и характер интерактивных эффектов;
обеспечить адаптивное отображение сайта на настольных компьютерах, планшетах и
мобильных устройствах;
реализовать общую навигацию сайта Фонда, включая переходы между главной
страницей, проектами, новостями, сведениями о Фонде и контактной информацией;
перенести все опубликованные страницы, тексты, изображения, логотипы, документы,
ссылки и иные материалы действующего сайта, кроме материалов, исключённых
Заказчиком;
сохранить существующие адреса страниц, а при невозможности — настроить
постоянные перенаправления с прежних адресов на соответствующие новые страницы;
обеспечить размещение сайта на действующем доменном имени, если иное не будет
установлено Заказчиком;
исключить зависимость функционирования от внешних конструкторов сайтов, не
используемых в Экосистеме;
обеспечить управление содержанием сайта через общую административную панель
Экосистемы.
9.8. Мобильное приложение
Мобильное приложение не заменяет адаптивные версии основных продуктов,
мобильные версии продуктов должны обеспечивать критические сценарии без
функциональной деградации. Мобильное приложение является самостоятельным
кроссплатформенным продуктом Экосистемы и дорабатывается в рамках настоящих
Работ.








главная, афиша, календарь, события, филиалы, поиск и материалы о Музее;
единая регистрация, профиль и личный кабинет;
билеты, QR-билеты, история покупок и заказов;
программа лояльности, достижения и задания;
избранное с синхронизацией между каналами;
push-уведомления и настройки;
аудиогиды, цифровые маршруты, сканер QR-кодов и AR-сценарии;
работа при нестабильной сети для заранее загруженных билетов и материалов в
безопасном объеме;
 сбор диагностических и продуктовых событий с учетом согласий;
 передача исходного кода, инструкций сборки, ключей и конфигураций без раскрытия
секретов в документации.
Подрядчик обязан подготовить промышленные сборки приложения, подписать их с
использованием учётных записей Заказчика и направить на публикацию в
предусмотренные Контрактом магазины приложений. Подрядчик устраняет замечания
магазинов, относящиеся к разработанному результату, и выполняет повторную подачу до
получения положительного решения. Отказ, обусловленный дефектом приложения,
нарушением правил площадки, неправильной конфигурацией или неполнотой
представленных материалов, является несоответствием результата ТЗ.
31
Публикация приложений для iOS и Android и их доступность пользователям в
магазинах приложений, определённых утверждённым ЧТЗ, являются обязательным
результатом этапа 3. Срок завершения этапа устанавливается пунктом 17.2.1 настоящего
ТЗ. Передача сборок на модерацию сама по себе не является выполнением требования о
публикации.
ЧТЗ определяет перечень магазинов приложений, территории распространения,
используемые учётные записи Заказчика и необходимые материалы для публикации.
Полный объём готовых контентных продуктов по пункту 9.10.12 передаётся на
этапе 3. Контрольные материалы не заменяют обязательный производственный объём.
9.8.1 Редизайн и доработка мобильного приложения
Мобильное приложение уже реализовано на Flutter, в рамках работ выполняются
его редизайн под единую дизайн-систему экосистемы и встраивание сквозных сервисов
(единый личный кабинет, программа лояльности и другие). Состав работ:
1. Редизайн экранов приложения под единую дизайн-систему экосистемы. Экраны к
редизайну















Загрузочный экран (splash)
Главная
Афиша / список событий (календарь, фильтры)
Страница события
О музее
Филиалы
Сканер QR-кодов
Вход / регистрация / восстановление пароля
Личный кабинет (профиль)
Мои билеты (+ электронный билет с QR-кодом)
История покупок / заказы
Избранное (синхронизация с сайтом и магазином)
Программа лояльности (баланс, история операций)
Результаты поиска
Пуш-уведомления / настройки
2. Интеграция и доработка основного функционала






Интеграция с единым личным кабинетом Экосистемы — сквозная авторизация,
единые данные пользователя, восстановление доступа, редактирование профиля.
Базовая программа лояльности в приложении — баланс, история операций;
интеграция с билетной системой и магазином.
Поиск по приложению.
Интеграция с билетной системой — покупка билетов, отображение приобретенных
билетов в профиле.
Пуш-уведомления и обратная связь.
Обязательная документация (инструкции, описание кодовой базы, сборка).
32

Модуль дополненной реальности (AR) и аудиогиды — реализация обязательных
пилотных маршрутов и аудиогидов в объеме, установленном пунктом 9.10.12
настоящего ТЗ.
Подрядчик проводит аудит существующей серверной части и представляет отчёт о
её архитектуре, безопасности, производительности, документации, правах на исходный
код, возможности сборки, развёртывания, сопровождения и интеграции с единым
пользовательским контуром Экосистемы.
Если существующая серверная часть соответствует требованиям ТЗ и может быть
передана Заказчику для независимой эксплуатации и развития, Подрядчик выполняет её
доработку и интеграцию. Если выявленные ограничения невозможно устранить
доработкой без существенного архитектурного или эксплуатационного риска, Подрядчик
выполняет контролируемую замену серверной части. Решение утверждается Заказчиком и
не может уменьшать состав функций, данных, интеграций и сценариев, предусмотренных
ТЗ. Оба варианта входят в цену Контракта.
9.9. Программа лояльности














единый баланс для сайта, магазина и приложения;
начисление за билеты, товары и согласованные действия;
списание при оплате в разрешенных каналах, уточняемых в ЧТЗ;
уровни участия, достижения, награды, привилегии и сроки действия;
настраиваемые правила с датами действия, приоритетами, ограничениями и аудитом
изменений;
промокоды, сертификаты и специальные кампании в согласованном составе;
семейные или групповые механики;
события посещения филиалов, аудиогидов, заданий и AR-сценариев;
защита от повторного начисления, подмены событий, автоматизированных
злоупотреблений и ручных ошибок;
ручная корректировка только уполномоченной ролью с указанием основания и
журналированием;
выгрузка реестра операций и сверка с источниками;
все подтверждённые операции лояльности должны регистрироваться в журнале
операций с уникальным идентификатором, датой и временем, основанием,
источником, значением баланса до и после операции и признаком повторной
обработки;
журнал операций должен обеспечивать восстановление подтверждённых начислений,
списаний, отмен и корректировок без логической потери операций при
восстановлении Экосистемы.
конкретные механики уточняются Заказчиком и фиксируется в ЧТЗ на этапе
обследования в пределах базовой механики.
9.10. Игровые механики, AR и аудиогиды
Экосистема должна обеспечивать создание и использование игровых механик,
направленных на повышение вовлеченности посетителей, стимулирование изучения
музейных материалов, посещения объектов и мероприятий Музея, использования
цифровых сервисов и повторного взаимодействия с Музеем.
33
Игровые механики должны быть связаны с личным кабинетом, мобильным
приложением, программой лояльности, профилем посетителя, музейным контентом и
иными сервисами Экосистемы.
Подрядчик разрабатывает и производит под ключ контент обязательных пилотных
игровых маршрутов, AR-маршрутов и аудиогидов. Заказчик предоставляет доступные
исходные музейные материалы, выполняет научную проверку и согласовывает
содержание.
В состав производства входят концепции, сценарии, тексты, графика, 2D- и 3Dматериалы, аудиозапись, озвучивание, монтаж, программно-техническая сборка,
тестирование и подготовка к публикации в объеме, необходимом для полноценной работы
согласованных пилотов.
Подрядчик отвечает за правомерность использования привлеченных изображений,
музыки, голосов, шрифтов, моделей и иных материалов. Исключительные права на
специально созданные результаты, а также редактируемые исходные файлы передаются
Заказчику в порядке, установленном Контрактом.
Игровые механики включают, но не ограничиваются:










конструктор либо управляемый набор заданий, маршрутов, достижений и наград;
привязка к филиалам, событиям, музейным предметам, экспозициям и цифровым
материалам;
условия выполнения по событию, времени, месту, коду, сканированию или
подтвержденному действию;
интеграция результатов с программой лояльности;
поддержка сценариев для детей, семей и образовательных групп;
управление мультимедийным контентом и версиями;
режим предварительного просмотра и тестирования;
доступность альтернативного контента для пользователей, которые не могут
использовать AR или аудио;
сбор статистики прохождения без избыточного наблюдения за пользователем;
документация интерфейсов для подключения новых игровых и AR-модулей.
9.10.1 Система игровых активностей
Экосистема должна поддерживать игровые активности различных типов, включая:

задания, выполняемые в цифровых сервисах и при физическом посещении объектов
Музея;
 музейные квесты и маршруты;
 викторины и иные формы проверки знаний;
 взаимодействие с музейными предметами, экспозициями и цифровым контентом;
 сканирование QR-кодов и иных идентификаторов;
 использование дополненной реальности;
 посещение объектов, выставок, мероприятий и отдельных локаций Музея;
 индивидуальное и групповое прохождение заданий;
 специальные, временные, сезонные и событийные игровые активности.
Подрядчик должен обеспечить возможность добавления новых типов игровых
активностей и их параметров без переработки базовой архитектуры Экосистемы.
34
9.10.2 Задания и условия выполнения
Для игровой активности должна обеспечиваться возможность устанавливать:












наименование, описание и визуальные материалы;
тип активности;
условия начала и завершения;
последовательность прохождения;
территориальные и временные ограничения;
обязательные и необязательные этапы;
целевую аудиторию и условия доступности;
количество попыток;
правила индивидуального или группового прохождения;
начисляемые баллы, достижения и иные результаты;
срок доступности;
основания отмены или аннулирования результата.
Система должна автоматически фиксировать начало, ход и завершение активности,
если это допускается соответствующим сценарием.
9.10.3 Баллы и игровой прогресс
Экосистема должна поддерживать начисление баллов или иных условных единиц
за действия посетителя.
Должна обеспечиваться возможность:









устанавливать количество начисляемых баллов для каждого действия;
задавать однократное или повторное начисление;
ограничивать количество начислений за установленный период;
устанавливать срок действия баллов;
использовать разные виды баллов, если это предусмотрено утвержденной моделью;
корректировать, отменять или восстанавливать начисления;
просматривать историю начислений и списаний;
определять правила перехода пользователя между уровнями;
информировать пользователя о текущем прогрессе и условиях достижения
следующего уровня.
Параметры начисления, ограничения и пороговые значения должны настраиваться
уполномоченными сотрудниками Заказчика без изменения программного кода.
9.10.4 Статусы, уровни и достижения
Экосистема должна поддерживать многоуровневую систему статусов и
достижений.
Должна обеспечиваться возможность:






создавать и изменять статусы, уровни и достижения;
определять условия их получения и утраты;
задавать последовательность уровней;
устанавливать требуемое количество баллов, выполненных заданий или иных условий;
присваивать достижения автоматически либо после подтверждения уполномоченным
сотрудником;
отображать статус, достижения и прогресс в профиле пользователя;
35



использовать визуальное оформление статуса, включая значок, рамку профиля или
иной графический элемент;
уведомлять пользователя о получении достижения или изменении статуса;
сохранять историю полученных статусов и достижений.
9.10.5 Вознаграждения
Экосистема должна поддерживать предоставление цифровых и материальных
вознаграждений за достижение установленных результатов.
Для вознаграждения должна обеспечиваться возможность задавать:










тип и описание;
основание предоставления;
количество доступных единиц;
срок действия;
условия получения и использования;
способ выдачи или активации;
ограничения по пользователям и количеству получений;
необходимость подтверждения сотрудником;
статус предоставления;
основания отмены или замены.
Система должна исключать повторную выдачу вознаграждения при отсутствии
соответствующего основания и вести историю его предоставления.
9.10.6 Квесты и маршруты
Экосистема должна обеспечивать создание и прохождение индивидуальных и
групповых квестов, маршрутов и иных последовательностей заданий.
Должны поддерживаться:









последовательные и вариативные сценарии прохождения;
задания, привязанные к музейным объектам и локациям;
подтверждение выполнения посредством QR-кода, геолокации, ответа на вопрос,
взаимодействия с контентом или иным предусмотренным способом;
сохранение промежуточного результата;
продолжение прерванного прохождения;
групповое прохождение с присоединением участников;
отображение результата участника или группы;
начисление баллов и выдача достижений;
возможность поделиться результатом с учетом настроек конфиденциальности
пользователя.
9.10.7 Викторины
Экосистема должна обеспечивать создание тематических викторин с различными
типами вопросов, вариантами ответов, ограничением времени, автоматической проверкой
результатов и начислением баллов.
Административный интерфейс должен позволять устанавливать:



состав и последовательность вопросов;
правила случайного выбора вопросов;
количество попыток;
36





время ответа;
правила подсчета результата;
условия успешного прохождения;
начисляемые баллы и достижения;
период доступности викторины.
9.10.8 Дополненная реальность
Игровые сценарии могут предусматривать использование дополненной реальности
для взаимодействия с музейными объектами, экспозициями, пространствами и
цифровыми персонажами.
Экосистема должна обеспечивать архитектурную возможность:






запускать AR-сценарий из мобильного приложения;
привязывать сценарий к объекту, изображению, метке или локации;
отображать графические, текстовые, звуковые, видео- и трехмерные материалы;
предусматривать интерактивные точки и действия пользователя;
фиксировать предусмотренные сценарием результаты взаимодействия;
передавать результат в профиль, систему достижений, программу лояльности и
аналитику.
Конкретные AR-сценарии, персонажи, композиции, способы взаимодействия и
визуальные решения определяются отдельными сценарными и проектными материалами.
9.10.9 Групповые механики
Экосистема должна поддерживать создание пользовательских групп для
совместного прохождения отдельных игровых активностей.
Должны быть предусмотрены:








создание группы и приглашение участников;
присоединение по ссылке, коду или иному идентификатору;
назначение организатора группы;
отображение состава и результатов участников;
выход участника и прекращение существования группы;
ограничение количества участников;
защита от несанкционированного присоединения;
соблюдение требований к персональным данным и приватности.
9.10.10 Защита от злоупотреблений
Экосистема должна предусматривать механизмы выявления и предотвращения:






повторного выполнения однократных заданий;
многократного начисления баллов за одно действие;
использования недействительных или скопированных идентификаторов;
искусственного создания активности;
неправомерного получения вознаграждений;
изменения результатов неуполномоченными пользователями.
Спорные начисления и результаты должны допускать проверку, корректировку или
аннулирование уполномоченным сотрудником с обязательным журналированием
операции.
37
9.10.11 Аналитика
По игровым механикам должны собираться как минимум следующие события:








начало и завершение активности;
прохождение отдельных этапов;
успешное и неуспешное выполнение;
отказ или прекращение прохождения;
начисление и отмена баллов;
получение статуса, достижения или вознаграждения;
использование AR-механики;
создание группы и участие в ней.
Заказчику должны быть доступны показатели востребованности механик,
конверсии начала в завершение, повторного участия, распределения пользователей по
уровням и влияния игровых активностей на посещение и использование сервисов Музея.
9.10.12. Обязательный объем реализации и пилотного наполнения
Объект
Обязательный объем
Критерий приемки
Игровые
маршруты
Не менее 2 полностью работающих
маршрутов; каждый включает не
менее 8 связанных заданий.
Маршрут запускается,
сохраняет прогресс, корректно
завершает задания и
однократно выдает
предусмотренный результат.
AR-маршруты
Не менее 2 полностью работающих
маршрутов с согласованным
набором точек и мультимедийных
объектов.
Маршруты работают на
поддерживаемых устройствах,
передают результаты в
профиль и аналитику и имеют
доступную альтернативу.
Аудиогиды
Не менее 2 полностью
подготовленных и опубликованных
аудиогидов.
Воспроизведение, навигация,
прогресс, аналитика и
предусмотренные
альтернативы работают в
согласованных каналах.
Производство
контента
Концепции, сценарии, тексты,
графика, 2D/3D, аудиозапись,
озвучивание, монтаж и техническая
сборка выполняются Подрядчиком.
Передан и опубликован
полный комплект
согласованного контента;
научные замечания Заказчика
устранены.
Администриро
вание
Все пилоты создаются и
редактируются через
административную систему без
доработки программного кода для
типовых операций.
Сотрудник Заказчика
изменяет контент, порядок,
условия и публикацию на
приемочном примере.
Аналитика
Фиксируются запуск, этапы,
завершение, отказ, ошибки и
предусмотренные результаты.
События доступны в
согласованном аналитическом
контуре и не дублируются.
Языки
Перевод пилотного музейного
Отсутствие EN-контента не
38
Объект
Обязательный объем
Критерий приемки
контента
контента Подрядчиком не
требуется; интерфейсные элементы
доступны на RU/EN.
нарушает интерфейс и
однозначно обрабатывается
системой.
Права и
исходники
Передаются права и редактируемые
исходные файлы; сторонние
материалы включаются на
законном основании.
Передан реестр прав,
лицензий и исходников,
достаточный для дальнейшего
изменения пилотов.
Обязательные пилоты подтверждают работоспособность платформы,
административных инструментов, аналитики и сквозных пользовательских сценариев.
Массовое производство последующих маршрутов и аудиогидов в объем Работ не входит.
Количество точек каждого AR-маршрута, состав мультимедийных объектов,
количество остановок и продолжительность каждого аудиогида определяются
утверждённым ЧТЗ. Указанные параметры согласовываются в составе проектирования
контентных продуктов к КТ-2. ЧТЗ не может уменьшать установленные настоящим
пунктом минимальное количество продуктов и обязательный состав результатов их
производства.
9.11. Обращения, чат и CRM










формы обращений по типам тем и услуг;
чат-виджет или эквивалентный канал;
создание обращения в клиентском контуре с уникальным номером;
подтверждение пользователю и доступный статус;
маршрутизация по ответственным подразделениям;
история коммуникаций и соблюдение сроков обработки;
передача только необходимых персональных данных;
обезличенная передача технических инцидентов в корпоративный портал;
разделение сервисных и маркетинговых коммуникаций;
аналитика причин обращений и качества обработки.
9.12. Уведомления







электронная почта, SMS и push в согласованном составе;
шаблоны, языковые версии и предварительный просмотр;
уведомления о регистрации, входе, билете, заказе, обращении, бонусной операции и
изменении важных условий;
очереди, повторная отправка и фиксация результата доставки;
отдельное управление сервисными и маркетинговыми согласиями;
защита от повторных и избыточных отправок;
журнал отправок и причин отказа без раскрытия секретов.
9.13. Аналитика и отчетность
Подрядчик обязан разработать и согласовать с Заказчиком каталог аналитических
событий и паспорт показателей.
Каждое аналитическое событие должно содержать:


уникальный код;
наименование;
39












описание;
условие возникновения;
источник;
обязательные параметры;
идентификатор сеанса;
экосистемный идентификатор пользователя при наличии основания;
версию схемы;
требования к согласию;
получателей;
срок доставки;
правила исключения дублей;
контроль качества.
Для каждого показателя должны быть определены ответственное подразделение
или должностное лицо, методика и формула расчета, источники данных, периодичность
обновления, правила фильтрации, а также порядок учета возвратов, отмен, некорректных
и дублирующихся данных. Должен быть обеспечен следующий функционал:


единый план событий и параметров для сайта, магазина и приложения;
воронки: просмотр события — переход к покупке — результат; просмотр товара —
корзина — заказ; регистрация — повторное посещение; участие в лояльности;
 события поиска, фильтров, ошибок, обращений, уведомлений и интеграций;
 отчеты по посещаемости, аудитории, контенту, конверсии, продажам, лояльности и
обращениям;
 технические панели и отчёты доступности, ошибок, времени ответа и состояния
интеграций;
 разграничение доступа и исключение необоснованного вывода персональных данных;
 документирование формул показателей и источников данных;
 экспорт отчетов в распространенные форматы.
Разработанные паспорта событий и показателей не могут быть менее полными, чем
минимальные паспорта согласно приложению №9.
10. Требования к данным и миграции
10.1. Основные сущности












Пользователь и профиль
Согласие и версия согласия
Филиал, здание, помещение и маршрут
Событие, сеанс и билет
Музейный предмет, коллекция и цифровой материал
Новость, проект и публикация
Товар, категория, цена, остаток и заказ
Бонусный счет, операция, правило, достижение и награда
Обращение и коммуникация
Уведомление и статус доставки
Игровой маршрут, задание и прохождение
Метрика, событие аналитики и технический инцидент
40
10.2. Источники достоверных данных
Для каждой сущности определяется система — источник достоверных данных.
Дублирование редактируемых мастер-данных в нескольких системах не допускается без
утвержденного механизма синхронизации, приоритетов и разрешения конфликтов.
Минимальное распределение авторитетных источников, потребителей данных и
правил их использования устанавливается Приложением № 2.
10.3. Качество данных








уникальность идентификаторов;
валидация обязательных полей и справочников;
контроль форматов, дат и связей;
дедубликация пользователей и объектов;
история изменений критичных данных;
контроль полноты интеграционного обмена;
сверка операций лояльности, билетов и заказов;
отчеты об ошибках качества данных.
10.4. Миграция
Миграция выполняется в составе, установленном Приложением № 11, по
утвержденному плану, включающему инвентаризацию источников, правила
преобразования, пробную миграцию, очистку, сопоставление, итоговую загрузку, сверку,
протокол полноты и процедуру отката.
Состав, объём, правила и критерии приёмки миграции определяются Приложением
№ 11. Уточнение матрицы по результатам инвентаризации не может приводить к
исключению обязательных объектов миграции.
11. Требования к архитектуре интеграционного взаимодействия и
данным
11.1. Общая архитектура
Создаваемая цифровая экосистема Музея представляет собой совокупность
взаимосвязанных информационных систем, цифровых сервисов и программных
компонентов, функционирующих как единое информационное пространство.
Архитектура цифровой экосистемы должна обеспечивать возможность
последовательного развития, модернизации и масштабирования отдельных компонентов
без необходимости переработки архитектуры экосистемы в целом.
При проектировании архитектуры подрядчик обязан обеспечить соблюдение
принципов модульности, расширяемости, технологической независимости, повторного
использования сервисов, единства данных и минимизации связанности между
компонентами. То есть должны быть выполнены следующие пункты, но не ограничиваясь
ими:




согласованное взаимодействие всех компонентов цифровой экосистемы;
отсутствие необоснованного дублирования функций и данных;
возможность независимого развития и замены отдельных компонентов;
подключение новых информационных систем и цифровых сервисов без полной
переработки существующей архитектуры;
41




технологическую нейтральность;
централизованное управление интеграционными интерфейсами;
контролируемое использование, передачу и изменение данных;
выполнение требований информационной безопасности и законодательства
Российской Федерации.
Конкретные программные продукты, технологии и способы реализации
определяются Подрядчиком на этапе архитектурного проектирования и подлежат
согласованию с Заказчиком.
11.2 Основные архитектурные принципы
При проектировании и реализации цифровой экосистемы Подрядчик обязан
соблюдать следующие принципы:










Единство экосистемы. Все компоненты должны использовать согласованные правила
интеграции, идентификации, управления данными и безопасности.
Модульность и слабая связанность. Изменение или замена одного компонента не
должны требовать полной переработки других компонентов.
Разделение предметных областей. Для каждой системы должны быть определены её
функции, данные и границы ответственности.
Единственный авторитетный источник. Для каждой критичной сущности должен
быть определён главный источник данных. Другие системы могут использовать только
управляемые производные копии.
Взаимодействие через документированные интерфейсы. Прямой доступ одной
системы к внутренней базе данных другой системы в качестве целевого способа
интеграции не допускается.
API First. Интеграционные интерфейсы должны проектироваться, документироваться
и согласовываться до их реализации.
Обоснованный выбор способа обмена. Синхронный, асинхронный или пакетный
обмен выбирается с учётом требований конкретного бизнес-сценария.
Версионирование и обратная совместимость. Изменения интерфейсов и схем
данных не должны нарушать работу действующих потребителей без
предусмотренного периода миграции.
Наблюдаемость. Состояние интеграций и прохождение критичных операций должны
подлежать централизованному контролю.
Технологическая независимость. Архитектура не должна создавать необоснованную
зависимость Заказчика от конкретного производителя или Подрядчика.
11.3 Единый интеграционный контур
В цифровой экосистеме должен быть реализован единый управляемый
интеграционный контур, обеспечивающий взаимодействие внутренних и внешних
информационных систем.
Интеграционный контур должен обеспечивать в применимой части:




публикацию и вызов API;
синхронный и асинхронный обмен;
публикацию и доставку событий;
маршрутизацию;
42










преобразование и проверку форматов данных;
аутентификацию и авторизацию систем;
управление версиями;
ограничение нагрузки;
журналирование;
мониторинг;
обработку ошибок;
повторную доставку;
предотвращение повторного выполнения операций;
подключение новых поставщиков и потребителей данных.
Под единым интеграционным контуром понимается совокупность согласованных
программных компонентов и правил. Применение одного централизованного
программного продукта не является обязательным. Реализация интеграционного контура
должна обеспечивать централизованное управление, мониторинг и журналирование,
независимо от того, используется ли для этого один продукт или несколько компонентов.
Не допускается создание новых неконтролируемых интеграций в обход
утверждённой архитектуры.
Минимальный состав интеграционных взаимодействий устанавливается
Приложением № 8. По результатам обследования Подрядчик уточняет доступность
методов, форматы, частоту обмена, ограничения и режимы деградации. Уточнение
интеграционных контрактов не может исключать интеграцию, прямо предусмотренную
настоящим Техническим заданием.
Конкретные внешние сервисы указаны исходя из действующих договоров и
инфраструктуры Заказчика (совместимость с ранее внедрёнными системами — п. 1 ч. 1
ст.33 Федерального закона № 44-ФЗ).
11.4 Требования к API и интеграционным контрактам
Каждый межсистемный интерфейс должен иметь документированный
интеграционный контракт.
Интеграционный контракт должен включать:











назначение взаимодействия;
поставщика и потребителя;
владельца;
состав и семантику передаваемых данных;
формат запросов, ответов или сообщений;
правила аутентификации и разграничения доступа;
способы обработки ошибок;
требования к производительности и доступности;
правила версионирования;
порядок изменения и прекращения поддержки;
порядок тестирования.
Спецификации API должны быть представлены в машиночитаемом и
человекочитаемом видах.
Все API должны быть зарегистрированы в едином каталоге с указанием владельца,
версии, статуса, потребителей и действующей спецификации.
43
Несовместимые изменения API должны реализовываться в новой версии с
обеспечением периода миграции действующих потребителей.
11.5 Синхронный и асинхронный обмен
Синхронное взаимодействие должно применяться для операций, требующих
немедленного результата.
Для синхронных взаимодействий должны быть определены:





предельное время ожидания;
правила повторных запросов;
режим работы при недоступности зависимой системы;
защита от каскадных отказов и перегрузки;
предотвращение повторного выполнения бизнес-операций.
Асинхронное взаимодействие должно применяться для распространения
изменений, фоновой обработки, взаимодействия с временно недоступными системами и
иных процессов, допускающих отложенную согласованность.
Для асинхронного взаимодействия должны быть предусмотрены:








уникальная идентификация сообщений;
версионирование схем;
контроль доставки;
повторная доставка;
изоляция необработанных сообщений;
возможность контролируемого повторного запуска;
предотвращение повторной обработки бизнес-операций;
мониторинг задержек и ошибок.
При использовании событийной модели все события должны быть
зарегистрированы в каталоге событий с указанием их назначения, производителя, схемы,
версии и правил доставки.
11.6 Архитектура данных
Подрядчик обязан разработать концептуальную модель данных цифровой
экосистемы.
Для каждой общей или критичной сущности должны быть определены:










наименование и единое определение;
предметная область;
авторитетный источник;
владелец данных;
уникальный идентификатор;
основные атрибуты;
потребители;
правила создания и изменения;
требования к качеству;
сроки и правила хранения.
Единая модель данных не означает обязательного создания единой физической
базы данных.
44
Для межсистемного обмена общими сущностями должны использоваться
согласованные модели данных, не зависящие от внутренней структуры конкретных
информационных систем.
Каждая система должна сохранять идентификаторы авторитетного источника. Для
общих сущностей должны применяться устойчивые экосистемные идентификаторы, не
зависящие от изменяемых бизнес-атрибутов.
11.7 Мастер-данные, справочники и НСИ
Для мастер-сущностей должны быть установлены:







авторитетные источники;
владельцы;
правила идентификации;
правила выявления и устранения дублей;
порядок распространения изменений;
допустимые сроки рассогласования;
правила сверки данных.
Требование к управлению мастер-данными не означает обязательного
приобретения отдельной MDM-системы.
Общие справочники и классификаторы должны иметь владельца, версию, статус,
период действия и установленный механизм распространения.
Исторические данные должны сохранять возможность корректной интерпретации
после изменения справочника.
11.8 Управление и качество данных
Подрядчик обязан разработать регламент управления данными, определяющий:







владельцев и кураторов данных;
порядок изменения моделей и справочников;
порядок предоставления доступа;
порядок разрешения противоречий;
требования к качеству;
порядок устранения ошибок;
правила архивирования, обезличивания и удаления.
Для критичных данных должны быть установлены измеримые показатели качества,
включая в применимой части:






полноту;
точность;
непротиворечивость;
уникальность;
актуальность;
соответствие установленным форматам и справочникам.
Для персональных, финансовых, музейных и аналитических данных должна
обеспечиваться прослеживаемость от источника до конечного потребителя в объёме,
необходимом для контроля, аудита и расследования инцидентов.
45
11.9 Музейные данные и электронный каталог
КАМИС должен рассматриваться как авторитетный источник учётных и научных
данных о музейных предметах, если иное не будет установлено по результатам
обследования.
Действующий электронный каталог «Коллекция онлайн» должен рассматриваться
как самостоятельный публичный компонент цифровой экосистемы.
Создание второй равноправной мастер-копии музейного каталога в официальном
сайте, мобильном приложении, CRM/CDP, BI-платформе или иных сервисах не
допускается.
Публичные и аналитические сервисы должны получать разрешённые к
использованию музейные данные через документированные интерфейсы, выгрузки или
производные индексы.
Прямое подключение публичных сервисов к производственной базе данных
КАМИС не допускается.
На этапе обследования Подрядчик обязан оценить применимость открытых
стандартов обмена и представления музейных данных и цифровых объектов. Результаты
оценки и предлагаемое решение должны быть представлены Заказчику на согласование.
11.10 Журналирование, мониторинг и ошибки
Все критичные интеграционные операции должны журналироваться с
использованием идентификаторов, обеспечивающих сквозное прослеживание
взаимодействия.
Журналы не должны содержать пароли, ключи, токены доступа и избыточные
персональные данные.
Мониторинг должен обеспечивать контроль:








доступности;
времени ответа;
ошибок;
пропускной способности;
задержек доставки;
повторных попыток;
необработанных сообщений;
актуальности синхронизации данных.
Ошибки интеграции должны регистрироваться и обрабатываться без молчаливой
потери данных.
Для критичных ошибок должны быть предусмотрены автоматические уведомления
и порядок эскалации.
11.11 Безопасность интеграционного взаимодействия
Передача защищаемой информации должна осуществляться по защищённым
каналам с обеспечением аутентификации сторон и контроля целостности, должно быть
обеспечено маскирование персональных данных и секретов в журналах.
Доступ к интерфейсам и данным должен предоставляться по принципу
минимально необходимых полномочий.
46
Для межсистемных взаимодействий должны применяться отдельные
идентифицируемые технические субъекты.
Изменения прав доступа, интерфейсов, схем данных, маршрутов и критичных
интеграционных настроек должны подлежать аудиту.
Конкретные требования по защите информации устанавливаются в разделе
информационной безопасности Технического задания.
11.12 Производительность, масштабируемость и отказоустойчивость
Интеграционная архитектура должна обеспечивать рост количества пользователей,
операций, данных, компонентов и внешних потребителей без полной переработки
существующих интеграционных контрактов.
Для критичных интеграций должны быть установлены:






показатели производительности;
показатели доступности;
допустимая задержка данных;
RTO и RPO;
режимы деградации;
порядок восстановления.
Конкретные значения устанавливаются в разделе нефункциональных требований и
уточняются по результатам обследования и разработки нагрузочной модели.
11.13 Документирование и передача результатов
Подрядчик обязан передать Заказчику:











утверждённую архитектурную документацию;
матрицу интеграций;
каталог сервисов и API;
каталог событий при его наличии;
концептуальную модель данных;
перечень мастер-сущностей и источников;
схемы данных;
интеграционные контракты;
документацию по мониторингу и обработке ошибок;
инструкции по подключению новых систем;
документацию фактически реализованной архитектуры.
Требования к полноте комплекта и возможности
самостоятельной эксплуатации устанавливаются разделом
19, в том числе пунктом 19.1 настоящего ТЗ.11.14 Общие
критерии приёмки
Требования настоящего раздела считаются выполненными при условии, что:






разработана и утверждена целевая архитектура;
все реализованные интеграции отражены в матрице интеграций;
все интерфейсы имеют актуальные спецификации и интеграционные контракты;
определены авторитетные источники и владельцы критичных данных;
реализованы предусмотренные механизмы журналирования и мониторинга;
подтверждена обработка ошибок и повторная доставка данных;
47




подтверждено отсутствие повторного выполнения критичных бизнес-операций;
выполнены интеграционные, нагрузочные и отказные испытания;
отсутствуют несогласованные прямые подключения к внутренним базам данных;
Заказчику передан полный комплект документации.
Детальные сценарии, показатели и методики испытаний определяются в программе
и методике испытаний на основании требований настоящего Технического задания и
утверждённой архитектуры.
11.15. Внешние зависимости
Заказчик предоставляет имеющиеся доступы и документацию в сроки Контракта.
Подрядчик проверяет зависимость и фиксирует ограничения. Отсутствие отдельного
метода внешней системы освобождает Подрядчика только от объективно зависимой
функции и не прекращает выполнение иных Работ. Альтернативный способ и влияние на
сроки оформляются мотивированным протоколом и утверждаются Заказчиком.
12. Технологические требования
12.1 Общие принципы





разработка, испытания, подготовка выпуска и эксплуатация осуществляются в
технологических средах, предусмотренных пунктом 12.2 настоящего ТЗ; публикация в
промышленную среду выполняется только после проверки версии в тестовой и
предпромышленной средах;
для каждого релиза оформляется журнал выпуска версии;
до продуктивного релиза создается точка восстановления;
для каждого продуктивного релиза должен быть определен и проверен порядок отката;
доступ к промышленной среде ограничивается ответственными лицами и фиксируется
в журнале действий.
12.2 Технологические среды
Среда
Назначение
Разработка и
Среда разработки
автоматические проверки
Функциональное и
Тестовая среда
интеграционное
тестирование
Предпромышленная Проверка версии перед
среда
выпуском
Промышленная
Промышленная
среда
эксплуатация
Требования
Не содержит персональных данных;
доступ по ролям.
Управляемые тестовые данные;
подключение тестовых внешних
контуров.
Максимально близка к
промышленной конфигурации.
Ограниченный доступ, мониторинг,
резервирование и журналирование.
12.2.1. Создание, владение и передача инфраструктуры
Подрядчик обязан подобрать, создать, настроить и подготовить к эксплуатации
облачную инфраструктуру Экосистемы у российского облачного провайдера с
размещением соответствующих данных и резервных копий на территории Российской
Федерации. Выбор провайдера и архитектура размещения согласовываются с Заказчиком.
Подрядчик создаёт и настраивает четыре изолированные среды: среду разработки,
тестовую, предпромышленную и промышленную. До публичного запуска этапа 1
подготавливаются промышленная и тестовая среды, средства сборки и развёртывания,
мониторинг, журналирование, резервное копирование и восстановление публикуемых
48
продуктов в объёме, необходимом для безопасной разработки и промышленной
эксплуатации публикуемых продуктов; на этапе 1 проверка версий перед публикацией по
пункту 12.1 выполняется в тестовой среде, КТ-2 подтверждает среды в объёме этапа 1.
Среда разработки и предпромышленная среда, а также полный сетевой контур по
настоящему пункту подготавливаются к этапу 2.
Учётные записи инфраструктуры и административный доступ Заказчика должны
быть оформлены и доступны Заказчику до запуска этапа 1.
Облачная организация, проекты, биллинг, домены, DNS, TLS-сертификаты,
система управления исходным кодом и автоматизацией сборки и развёртывания, система
мониторинга, хранилище секретов, резервное хранилище и иные эксплуатационные
ресурсы с момента создания регистрируются на юридическое лицо Заказчика. Подрядчику
предоставляются делегированные права доступа, которые могут быть отозваны
Заказчиком без утраты управления ресурсами.
Подключение к внутренним системам Музея выполняется через защищённый VPNтуннель и с применением сетевой сегментации. Необходимость выделенного канала
определяется утверждённой архитектурой и моделью угроз.
Подрядчик обязан обеспечить подключение промышленной среды Экосистемы к
сети Интернет с пропускной способностью, соответствующей нагрузочной модели,
установленной настоящим ТЗ, но не менее 100 Мбит/с для входящего и исходящего
трафика. Сетевая инфраструктура должна обеспечивать возможность увеличения
пропускной способности без изменения прикладной архитектуры Экосистемы и
длительного прекращения её работы.
Если для взаимодействия с внешними информационными системами требуется
включение источника запросов в списки разрешённых адресов, Подрядчик обязан
обеспечить использование одного или нескольких статических публичных IPv4-адресов,
выделенных исключительно для Экосистемы. Исходящие запросы серверных
компонентов Экосистемы к таким внешним системам должны выполняться через сетевой
шлюз, прокси-сервер или эквивалентное решение с использованием указанных адресов.
Перечень статических публичных IP-адресов, их назначение и связанные с ними
внешние информационные системы фиксируются в эксплуатационной документации и
реестре сетевых ресурсов.
Для приёма и распределения входящего трафика промышленной среды Подрядчик
обязан предусмотреть отказоустойчивый балансировщик нагрузки прикладного уровня L7
либо эквивалентное решение, исключающее единую точку отказа и обеспечивающее:

маршрутизацию запросов по доменным именам и путям URL;

проверку работоспособности обслуживающих компонентов и исключение
недоступного экземпляра из обработки запросов при наличии резервного
экземпляра;

сохранение и передачу исходного IP-адреса клиента обслуживающим компонентам
посредством доверенного стандартного заголовка либо эквивалентного механизма;

ограничение частоты запросов и числа соединений в соответствии с
установленными правилами;
49

регистрацию запросов с указанием даты и времени с часовым поясом, исходного
IP-адреса, запрошенного ресурса, результата обработки и идентификатора запроса;

применение правил защиты веб-приложений от атак прикладного уровня.
Защита от сетевых атак должна включать средства противодействия DDoS-атакам
на сетевом и транспортном уровнях, а также средства защиты веб-приложений,
ограничения частоты запросов и блокирования аномальной активности на прикладном
уровне.
Административные интерфейсы Экосистемы не должны быть общедоступными,
кроме случаев, прямо согласованных с Заказчиком. Доступ к ним должен ограничиваться
средствами аутентификации и сетевой фильтрации, VPN или эквивалентным
защищённым способом.
Облачная учётная запись, в которой создаются статические IP-адреса,
балансировщики, сетевые шлюзы и иные сетевые ресурсы промышленной среды, должна
быть зарегистрирована на Заказчика и находиться под его административным контролем
до публичного запуска соответствующих компонентов. Подрядчик обязан передать
Заказчику описание сетевой архитектуры, настройки маршрутизации и фильтрации,
перечень ресурсов и инструкции по их администрированию.
Подрядчик выполняет миграцию существующих развёртываний компонентов, входящих в
состав Экосистемы, в создаваемую инфраструктуру.
До начала миграции Подрядчик обязан провести инвентаризацию существующих
развёртываний, зафиксировать их конфигурацию и исходное состояние, подготовить
резервные копии, план миграции, критерии проверки результата, допустимый период
недоступности и план возврата к исходному состоянию.
План миграции и план возврата согласовываются с Заказчиком до начала работ.
Результат миграции подтверждается функциональными, интеграционными и
эксплуатационными проверками. Нарушения, возникшие вследствие миграции,
устраняются Подрядчиком за свой счёт
Подрядчик обязан передать Заказчику:







схему инфраструктуры и сетевого взаимодействия;
конфигурации и инфраструктурный код;
реестр ресурсов, учётных записей и административных ролей;
регламенты развёртывания, мониторинга, резервного копирования и восстановления;
порядок изменения мощностей и тарифов;
сведения о размещении и обработке персональных данных;
расчёт регулярных расходов по каждому сервису.
Стоимость инфраструктуры для разработки, испытаний и непрерывной
промышленной эксплуатации с декабрьского запуска до окончания этапа 4 включается в
цену соответствующих этапов Контракта без повторного учёта одних расходов. После
завершения этапа 4 регулярные платежи осуществляются Заказчиком в порядке,
установленном Контрактом.
12.3 Репозиторий и контроль версий

исходный код и инфраструктурные конфигурации хранятся в репозиториях Заказчика
либо в репозитории с полным административным контролем Заказчика;
50





история изменений и авторство сохраняются;
изменения проходят проверку кода;
релизные версии маркируются тегами;
запрещается передача только архивов без истории и процесса сборки;
в репозиторий не помещаются пароли, ключи и иные секреты.
12.4 Автоматизация сборки и выпуска







автоматизированная сборка воспроизводима на инфраструктуре Заказчика;
проверки качества, тесты и анализ зависимостей выполняются для релизной сборки;
артефакты имеют версию и контрольную сумму;
развертывание в тестовые среды автоматизировано;
выпуск в промышленную среду требует утвержденной процедуры и полномочий;
автоматизация сборки, тестирования и развертывания (CI/CD) является обязательной
для всех сред, кроме промышленной, где требуется подтвержденный ручной запуск;
миграции баз данных версионируются и имеют процедуру отката или компенсации.
12.5 Технологическая независимость
Использование конкретных продуктов допускается при объективной
необходимости совместимости с действующей инфраструктурой. В остальных случаях
требования описываются через характеристики результата. Подрядчик обязан раскрыть
перечень компонентов, лицензий, ограничений и затрат, необходимых для дальнейшей
эксплуатации.
13. Дизайн-система, интерфейсы и доступность
13.1 Требования к эргономике и технической эстетике
В качестве нормативно-технической документации при эргономическом
проектировании компонентов интерфейса Системы должны использоваться
государственные стандарты (в том числе стандарты серии ССЭТО и ГОСТ Р ИСО 9241110-2016. Национальный стандарт Российской Федерации. «Эргономика взаимодействия
человек-система. Часть 110. Принципы организации диалога»). Экранные формы должны
проектироваться с учетом требований унификации:

все экранные формы пользовательского интерфейса должны быть выполнены в
едином графическом дизайне, с одинаковым расположением основных элементов
управления и навигации;
 для обозначения одних и тех же операций должны использоваться одинаковые
графические значки, кнопки и другие управляющие (навигационные) элементы; −
должны быть унифицированы термины, используемые для описания идентичных
понятий, операций и действий пользователя;
 реакция Системы на действия пользователей (наведение указателя «мыши»,
переключение фокуса, нажатие кнопки) должна быть типовой для каждого действия
над одними и теми же графическими элементами, независимо от их расположения на
экране.
Пользовательские интерфейсы должны быть интуитивно понятными для
представителей соответствующих целевых групп и обеспечивать выполнение критических
пользовательских сценариев без предварительного обучения, обращения к внешним
инструкциям и обязательной помощи специалиста. Структура навигации, наименования
разделов, элементы управления, подсказки, обратная связь и сообщения об ошибках
51
должны быть последовательными, однозначными и соответствовать ожидаемой логике
действий пользователя.
Понятность и удобство использования проверяются в рамках пользовательского
приемочного тестирования по критическим сценариям, утвержденным Заказчиком.
Основанием для доработки являются систематические затруднения пользователей,
неоднозначность навигации или терминологии, ошибочные действия, вызванные
организацией интерфейса, а также невозможность завершить критический сценарий без
помощи модератора.
13.2 Единая дизайн-система
Единые для всех продуктов экосистемы — основного сайта, интернет-магазина и
мобильного приложения. Дизайн-макеты сдаются в состоянии, пригодном для передачи в
разработку без дополнительных уточнений, детальный перечень оформляется отдельной
спецификацией требований.








единая библиотека компонентов для сайта, личного кабинета, магазина и приложения;
дизайн-токены цвета, типографики, размеров, отступов, радиусов и состояний;
принцип «сначала мобильные»;
состояния normal, hover, focus, active, disabled, loading, empty и error;
адаптивные правила для настольных, планшетных и мобильных устройств;
документация по применению компонентов;
редактируемые исходники и права передаются Заказчику;
использование шрифтов и материалов только на законных основаниях.
13.3 Порядок согласования дизайна
Макеты передаются в состоянии, пригодном для разработки: полные экраны,
адаптивные варианты, состояния, тексты, правила поведения, компоненты и связи
прототипа. Количество итераций и сроки согласования устанавливаются планом;
исправление несоответствий ТЗ не считается дополнительной итерацией.
Заказчик имеет право требовать доработки дизайн-макетов на любом этапе их
разработки, если они не соответствуют его ожиданиям в части визуального стиля,
удобства использования или соответствия брендбуку. Такие доработки производятся
Подрядчиком в рамках согласованного объема работ и не считаются дополнительной
работой, если не выходят за пределы утвержденной структуры и не требуют изменения
технологического стека.
13.4 Доступность
Критические пользовательские сценарии веб-интерфейсов должны соответствовать
WCAG 2.2 уровня AA в применимой части и обязательным требованиям законодательства
Российской Федерации, указанным в Приложении № 5.






полная клавиатурная навигация;
видимый фокус;
текстовые подписи и сообщения об ошибках;
достаточная контрастность;
масштабирование текста и отсутствие потери функций;
текстовые альтернативы значимых изображений;
52




поддержка программ экранного доступа в критических сценариях;
отсутствие зависимости только от цвета, движения или наведения;
управление анимацией и автоматическим воспроизведением;
альтернативы для аудио, видео и AR-материалов.
Область обязательных, но не достаточных, проверок: главная страница, навигация,
афиша, карточка события, переход к покупке билета, авторизация, личный кабинет, QRбилет, история билетов, обращения, согласия, уведомления об ошибках, мобильная
версия.
13.5 Требования к качеству макетов
Основанием для отказа в приёмке является непригодность макетов к передаче в
разработку, а не отдельные отступления от пунктов ниже; специальные термины Figma —
мастер-компоненты, инстансы, variants, variable modes, Auto Layout и прочие —
употребляются в значении официальной документации Figma:
1. Дизайн-система / UI Kit — отдельный результат работ: переиспользуемые
элементы как master-компоненты, разложенные по категориям (токены, типографика,
компоненты, паттерны); иерархия токенов в 2–3 уровня (примитивы →семантические →
слой состояний); полный каталог компонентов со всеми вариантами (size, type) и
состояниями (default / hover / focus / active / disabled /error / loading); адаптивные токены
(брейкпоинты, контейнеры, межколоночные интервалы и внешние отступы —
переменными, а не по месту); темы и версия для слабовидящих — через variable modes, а
не отдельными перекрашенными экранами; краткий гайд по применению ключевых
компонентов и токенов.
2. Layout: Auto Layout на каждом фрейме и компоненте; Frames, а не Groups;
осознанный resizing (fill / hug / fixed) на каждом элементе; единая сетка отступов (шкала
4 / 8 px); Layout Grid на ключевых экранах.
3. Компоненты: повторяющиеся элементы — компонентами, а не дублированием;
variants и component properties с осмысленными именами (type, size, state); инстансы не
отсоединены от библиотеки (без detach); имена компонентов совпадают с будущими
именами в коде.
4. Стили и токены: все цвета, шрифты, радиусы, тени — через styles / variables, без
локальных значений; семантические имена (color/brand, text/secondary); ограниченный
набор текстовых стилей (кегль, line-height, letter-spacing, начертания заданы как text
styles); шрифты — только в коммерческой лицензии (Trial / Demo запрещены в
продакшене).
5. Нейминг и структура файла: слои названы по смыслу (HeroSection,
AfishaCard,не Frame 891); страницы организованы по фичам / флоу, черновики отделены
от финала; готовые экраны помечены статусом Figma «Ready for dev».
6. Состояния и крайние случаи: состояния интерактивных элементов (hover /
focus /active / disabled / error / loading) как варианты компонентов; состояния экранов
(пустой список, ошибка загрузки, индикаторы загрузки — skeleton/spinner); поведение
длинного контента (truncate / перенос / скролл) задано в макете.
7. Адаптивность макетов: ключевые брейкпоинты предоставлены макетами
(минимум desktop и mobile; планшет — если поведение не выводится однозначно);
поведение блоков между брейкпоинтами задано (отдельными фреймами либо resizing+
53
текстовое описание); адаптивная типографика зафиксирована; указаны точки
переключения раскладки.
Данные требования не исключают требований, заданных в Приложении № 3 к
настоящему ТЗ.
13.6. Интернационализация и языковые версии
Экосистема должна быть изначально реализована как мультиязычная. Русская и
английская локализации пользовательских интерфейсов являются обязательными и
поддерживаются сквозным образом во всех входящих в предмет Контракта
пользовательских компонентах и сценариях.

пользовательские тексты интерфейса хранятся вне программного кода в каталогах
локализации формата JSON либо в ином открытом машиночитаемом формате;
 для переводимых сообщений используются стабильные идентификаторы; жестко
заданные пользовательские тексты в программном коде не допускаются;
 обеспечиваются централизованные добавление, экспорт, импорт, редактирование и
публикация переводов;
 новый язык подключается путем регистрации языковой версии и загрузки каталога
переводов без изменения бизнес-логики, структуры базы данных и программных
компонентов;
 языковые версии могут независимо включаться и отключаться; система контролирует
полноту локализации интерфейсов и статус языковых вариантов контента;
 корректно локализуются даты, время, числа, валюты, формы множественного числа,
адреса и иные зависящие от языка значения;
 выбранный язык сохраняется при переходах между компонентами Экосистемы и
передается через API и интеграционные взаимодействия;
 переключение языка по возможности сохраняет текущий контекст пользователя:
страницу, событие, товар, билет, маршрут или иной объект;
 для веб-компонентов предусматриваются отдельные индексируемые URL языковых
версий, корректные атрибуты lang и hreflang, языковые карты сайта и метаданные;
 административный интерфейс может быть русскоязычным, но должен позволять
управлять русскими, английскими и последующими языковыми вариантами
интерфейсов и контента.
Требование RU/EN распространяется на навигацию, меню, кнопки, формы,
подсказки, сообщения об ошибках, статусы, результаты поиска, элементы личного
кабинета, билеты и заказы, правила и интерфейсы программы лояльности, сервисные
уведомления, email- и push-сообщения, а также интерфейсные элементы игровых, AR- и
аудиосценариев основного сайта, сайта Фонда, интернет-магазина и мобильного
приложения.
Перевод существующего текстового, музейного и иного внутреннего контента
Подрядчиком не выполняется. Названия и описания событий, коллекций, товаров,
публикаций, маршрутов и иных материалов могут быть представлены только на русском
языке. Отсутствие английской версии такого материала не является дефектом. При
отсутствии перевода система должна отображать русскую версию либо однозначно
сообщать пользователю об отсутствии перевода; выбор правила согласовывается с
Заказчиком.
54
При приемке Подрядчик обязан подключить демонстрационный третий язык,
загрузить тестовый каталог интерфейсных сообщений и подтвердить сквозное
переключение языка без изменения бизнес-логики и структуры данных. Перевод
внутреннего контента для данного испытания не требуется.
14. Нефункциональные и эксплуатационные требования
14.1. Производительность
Показатель
Целевое значение
LCP
не более 2,5 с на 75-м перцентиле
INP
не более 200 мс на 75-м
перцентиле
CLS
не более 0,1 на 75-м перцентиле
Ответ
собственного API
не более 500 мс для типовых
операций без внешних систем
Формирование
типового отчета
не более 30 с, если иной объем не
установлен
Область
Согласованный перечень
ключевых публичных
страниц, отдельно для
мобильных и настольных
устройств
Согласованный перечень
интерактивных страниц и
основных пользовательских
сценариев
Согласованный перечень
ключевых публичных и
интерактивных страниц
Типовые синхронные
операции чтения и записи, не
зависящие от времени ответа
внешних систем
Согласованные типы отчётов
при установленном объёме и
периоде данных
Методика измерения, профиль нагрузки, устройство, сеть, объем данных, прогрев и
допустимые исключения определяются программой испытаний до начала
соответствующего теста и утверждаются Заказчиком.
Проверка проводится отдельно для мобильного и настольного профилей при
условиях, установленных программой и методикой испытаний.
В состав нагрузочных и отказных испытаний включается проверка работы
балансировщика при пиковой нагрузке и имитации отказа одного из бэкендов.
Проверяется сохранение сессий и корректность маршрутизации при смене IP-адреса (при
его изменении).
14.1.1. Нагрузочная модель
Достоверная статистика существующего сайта не используется как основание для
снижения требований. До начала реализации соответствующих компонентов Подрядчик
детализирует нагрузочную модель с учетом рекламных кампаний, доступности билетов на
востребованные мероприятия и кратковременных всплесков. Значения не могут быть
уменьшены без изменения ТЗ.
Для каждой строки базовый и пиковый профили должны быть выражены в
одинаковом наборе показателей. Если используются одновременно количество активных
55
сессий и интенсивность операций, оба показателя указываются для базового и пикового
профилей.
Для этапа 1 количественные показатели нагрузки составляют 30 процентов
соответствующих значений нагрузочной модели настоящего пункта. Коэффициент
применяется к количеству одновременно активных пользователей и сессий,
интенсивности запросов и операций, а также к расчету инфраструктуры этапа 1; дробные
значения округляются вверх. Коэффициент не применяется к требованиям ко времени
ответа, допустимой доле ошибок, сохранности данных и продолжительности испытаний.
Начиная с этапа 2 применимые сценарии проверяются на полной установленной нагрузке.
Сценарий
Минимальная
нагрузка
Пиковая
нагрузка
Просмотр
публичных
страниц
1 000
активных
пользователей
одновременно
2 000
активных
пользователей
одновременно
Открытие
билетов /
продвижение
5 000 новых
сессий за 15
минут
Продолжи
тельность
Критерий
не менее
60 минут
p95 ответа серверной
части не более 1 с;
технические ошибки не
более 0,1%; Core Web
Vitals соответствуют ТЗ
до 2 000
одновременно
активных
пользователей
не менее
30 минут
нет потери контекста,
дублей операций и
неконтролируемого
отказа; механизм
ограничения нагрузки
работает
p95 не более 2 с;
технические ошибки не
более 0,1%
Поиск и
фильтрация
афиши
100 запросов/с
200 запросов/с
не менее
30 минут
Личный
кабинет,
авторизация,
билеты и
лояльность
300
одновременны
х сессий
600
одновременны
х сессий
не менее
30 минут
p95 не более 2,5 с;
успешность не ниже
99,9%; нет повторных
начислений
Сквозной
сценарий
покупки
200
одновременны
х
пользовательс
ких сценариев
не менее 20
запусков
операций/с
не менее
15 минут
заказы, билеты и
подтвержденные
операции не теряются и
не дублируются
Длительная
стабильная
работа
500
одновременны
х
пользователей
—
не менее 8
часов
нет роста ошибок,
неконтролируемого
потребления ресурсов и
деградации сверх
установленных
показателей
Стрессовый
тест
собственных
компонентов
4 000
активных
пользователей
либо 400
до выявления
фактического
предела
не менее
10 минут
на
предельно
зафиксирован предел;
деградация
контролируема; данные
не теряются и не
56
Сценарий
Минимальная
нагрузка
Пиковая
нагрузка
бизнесзапросов/с






Продолжи
тельность
Критерий
м уровне
повреждаются
статические материалы обслуживаются с применением кеширования и CDN либо
эквивалентного механизма;
для ажиотажного спроса реализуется виртуальная очередь либо иной согласованный
механизм ограничения нагрузки и контролируемой деградации;
при превышении расчетной нагрузки не допускаются потеря данных, повторное
списание, создание дублирующих заказов, билетов или начислений;
собственные компоненты испытываются на полной установленной нагрузке; внешние
системы — в пределах документированных лимитов их владельцев;
если внешняя система не допускает требуемое испытание, собственный контур
проверяется с использованием эмулятора или заглушки, воспроизводящей
согласованные задержки, ошибки и ограничения;
уточнение модели допускается в сторону детализации или увеличения нагрузки и
фиксируется в программе и методике испытаний.
14.2. Доступность и надежность






круглосуточная работа публичных критических сервисов, за исключением
согласованных окон;
целевой SLA критических сервисов — не ниже 99,5 процента в месяц, если
Контрактом не установлено более высокое значение;
плановые работы проводятся в согласованные периоды с предварительным
уведомлением;
отказы некритичных внешних систем не должны приводить к полной недоступности
сайта;
применяются тайм-ауты, ограничение повторов и автоматические защитные
механизмы;
после критического инцидента оформляется анализ причин и корректирующих мер.
14.2.1. Порядок расчета доступности
Доступность рассчитывается ежемесячно отдельно для каждого критического
сервиса по формуле:
где:
— доступность сервиса;

— общее время расчетного периода за вычетом согласованных плановых окон;

— суммарная продолжительность подтвержденной недоступности.
Недоступностью считается невозможность выполнить критический сценарий по
причине отказа компонента, находящегося в зоне ответственности Подрядчика.

Плановые работы исключаются из расчета только при одновременном соблюдении
условий:



Заказчик уведомлен не менее чем за 3 рабочих дня;
продолжительность окна согласована;
работы выполнены в согласованный период;
57

суммарное плановое время не превышает 4 часов в месяц.
Источником расчёта является система мониторинга, создаваемая и настраиваемая
Подрядчиком в рамках настоящего Контракта и находящаяся под административным
контролем Заказчика. При расхождении данных используются результаты совместного
анализа журналов и синтетических проверок.
14.3. Совместимость





актуальные поддерживаемые версии основных браузеров;
адаптивная работа на типовых размерах экранов;
поддерживаемые версии iOS и Android определяются с учетом статистики и
требований магазинов приложений;
корректная работа при медленном соединении и понятные состояния загрузки;
отсутствие критичных функций, доступных только в одном браузере без обоснования.
14.4. Резервное копирование и восстановление
RTO и RPO применяются к восстановлению после аварийного события и не
заменяют требования к повседневной доступности, резервированию компонентов и
автоматическому переключению при единичных отказах. Требования к RTO/RPO
настоящего пункта не применяются к 1 этапу и уточняются в ЧТЗ.
Класс
Сервисы и данные
RTO
RPO
Критические
транзакционные
сценарии
Авторизация, профиль, активные
билеты, заказы, операции
лояльности и подтвержденные
пользовательские действия
не более 2
часов
не более 15
минут
Публичные
информационные
сервисы
Основной сайт, сайт Фонда,
афиша, поиск и публичная часть
приложения
не более 4
часов
не более 1 часа
Внутренние
операционные
сервисы
Административная система,
управление контентом и
операторские интерфейсы CRM
не более 8
часов
не более 4 часов
Аналитика и фоновые
процессы
BI, отчетность, витрины и
повторно формируемые данные
не более 24
часов
не более 24
часов
Потеря подтвержденных операций покупки, выдачи билета, изменения статуса
заказа, начисления или списания баллов не допускается. После восстановления
Экосистема должна обеспечивать автоматическую либо управляемую сверку с системой
— источником данных, повторную обработку событий и устранение расхождений без
создания дублей.
При недоступности основного динамического контура не позднее чем через 30
минут должна быть опубликована резервная информационная страница либо доступна
сохраненная статическая версия основных публичных материалов с уведомлением о
временном ограничении отдельных функций.

начальным событием для исчисления срока восстановления является автоматическое
обнаружение сбоя мониторингом либо регистрация инцидента — в зависимости от
того, что произошло раньше. Учёт рабочего и календарного времени осуществляется в
58



соответствии с режимом поддержки, установленным пунктом 21.2. восстановлением
считается не запуск серверов, а успешное выполнение установленных контрольных
пользовательских и интеграционных сценариев;
плановые работы исключаются из расчета только в заранее согласованном окне;
RTO/RPO внешних систем не относятся к ответственности Подрядчика, однако он
обязан обеспечить корректную деградацию, журналирование, ограниченные повторы,
сверку и восстановление интеграционного обмена данными;
до приемки Подрядчик выполняет полное восстановление критических компонентов в
изолированной среде с измерением фактических RTO/RPO и оформлением протокола.
Показатели RTO и RPO применяются к инфраструктуре, создаваемой и
настраиваемой Подрядчиком в соответствии с утверждённой архитектурой. До передачи
Экосистемы Подрядчик несёт ответственность за работоспособность прикладных
компонентов, серверов, баз данных, резервного хранилища, инфраструктурного
резервирования, мониторинга и процедур восстановления в пределах созданной им
инфраструктуры.
Если к отдельным работам привлекается согласованный с Заказчиком
инфраструктурный или DevOps-подрядчик, ответственность между участниками
распределяется в утверждённой матрице ответственности. Такое распределение не
освобождает Подрядчика от обязанности обеспечить достижение предусмотренных ТЗ
показателей и организовать совместное восстановление Экосистемы.
Заказчик обеспечивает предоставление решений, доступов и организационное
взаимодействие в установленной за ним зоне ответственности, но не выполняет вместо
Подрядчика создание и первичную настройку инфраструктуры.

Тип копии
Периодичность
Срок хранения
Журнал транзакций /
инкрементальная копия
критических БД
с периодичностью и по
технологии,
обеспечивающими RPO,
установленный пунктом
14.4 для критических
транзакционных данных
не менее 7 суток
Полная ежедневная копия БД
ежедневно
не менее 30 суток
Недельная копия
еженедельно
не менее 12
недель
Месячная копия
ежемесячно
не менее 12
месяцев
Файлы и цифровые материалы
при изменениях, но не
реже одного раза в сутки
согласно
критичности и
объему
Конфигурации
при каждом изменении и
перед релизом
в течение срока
эксплуатации
соответствующей
версии
резервные копии шифруются при передаче и хранении;
59




хранятся отдельно от основной промышленной среды и защищаются от изменения или
удаления учетными записями промышленного контура;
проходят автоматический контроль успешности и целостности;
имеют документированный срок хранения и безопасно удаляются после его
окончания;
не создают неконтролируемых копий персональных данных.
При эксплуатации сроки восстановления исчисляются с учётом режима поддержки
по пункту 21.2. В период этапа 4 для критических инцидентов сроки исчисляются в
календарном времени; в остальные периоды и для иных приоритетов — в установленное
рабочее время поддержки, кроме согласованных работ Подрядчика вне рабочего времени.
При контрольных испытаниях техническая способность восстановления в пределах
установленных значений RTO проверяется по непрерывно измеряемому фактическому
времени. Значения RPO, периодичность резервного копирования, работа автоматических
механизмов отказоустойчивости и расчёт доступности сервисов не зависят от рабочего
времени специалистов.
Временное обходное решение учитывается как восстановление только при
условии, что соответствующий контрольный сценарий фактически выполняется, данные
не теряются и не повреждаются, а применённая мера не создаёт неприемлемых рисков
безопасности.
14.5. Наблюдаемость
С первого публичного запуска этапа 1 Подрядчик обеспечивает круглосуточное
функционирование автоматизированного мониторинга эксплуатируемых компонентов.
Режим участия специалистов Подрядчика и порядок исчисления сроков реакции и
восстановления определяются пунктами 14.4 и 21.2 настоящего ТЗ.








журналы приложения, интеграций, безопасности и административных действий;
метрики доступности, ошибок, задержек, очередей и ресурсов;
трассировка критических запросов по идентификатору корреляции;
синтетические проверки ключевых сценариев;
панели для технических специалистов и руководителей;
оповещения с приоритетами и матрицей эскалации;
сроки хранения журналов в соответствии с назначением и требованиями к данным;
инструкции диагностики типовых сбоев.
15. Информационная безопасность и персональные данные
15.1 Определение применимых требований
До утверждения окончательной архитектуры Подрядчик совместно с Заказчиком
уточняет категории данных, роли оператора, границы информационной системы, уровень
защищенности персональных данных, модель угроз и применимые обязательные меры.
Требования, относящиеся исключительно к государственным информационным системам
определенного класса, применяются только при наличии установленного правового
основания.
60
15.2 Требования к защите информации при выполнении работ
Экосистема должна обеспечивать защиту информации, персональных данных и
учетных записей от неправомерного доступа, изменения, уничтожения, блокирования,
копирования, предоставления и распространения. Подрядчик должен реализовать
разграничение прав доступа в соответствии с ролями пользователей, защищенную
передачу и хранение данных, безопасное управление учетными данными и секретами,
журналирование действий пользователей и администраторов, выявление подозрительной
активности, а также защиту игровых механик и программы лояльности от повторного
начисления баллов, подмены результатов, использования недействительных
идентификаторов и неправомерного получения вознаграждений. Состав мер определяется
с учетом результатов, предусмотренных пунктом 15.1.
Экосистема должна соответствовать действующим в Российской Федерации
законодательным актам, в том числе представленным в Приложении № 5, и отвечать
требованиям, предъявляемым к информационным системам, осуществляющим обработку
защищаемой информации.
Автоматизированное обнаружение и регистрация событий мониторинга
осуществляются круглосуточно с первого публичного запуска этапа 1. Реагирование
специалистов Подрядчика, включая критические инциденты и выполнение согласованных
работ вне рабочего времени, осуществляется в режиме, установленном пунктом 21.2
настоящего ТЗ.Круглосуточный режим реагирования ответственных специалистов
Подрядчика на критические инциденты применяется в периоды, установленные пунктами
18.6 и 21.2 настоящего ТЗ.
Круглосуточное реагирование также обеспечивается в согласованные периоды
выполнения Подрядчиком плановых работ в промышленной среде, включая
развертывание релизов, миграцию данных и изменение конфигурации, если такие работы
проводятся вне рабочего времени и могут повлиять на доступность, безопасность или
целостность данных Экосистемы.
В остальные периоды выполнения Работ, а также после завершения периода
стабилизации сроки реагирования и устранения гарантийных дефектов исчисляются в
пределах рабочего времени поддержки, если иной режим не установлен Контрактом или
отдельным договором сопровождения.
При выполнении работ Подрядчик должен обеспечить выполнение требований
действующего законодательства Российской Федерации в сфере защиты информации,
указанного в Приложении № 5, в том числе, обеспечить безопасность персональных
данных, а именно:
первичное автоматическое уведомление о критическом инциденте направляется
системой мониторинга круглосуточно не позднее 5 минут с момента его обнаружения или
регистрации по каналам и информации согласно матрице определенной в Приложении №
12 к настоящему ТЗ.


. Направление автоматического уведомления само по себе не означает
круглосуточного дежурства специалистов Подрядчика за пределами периодов, прямо
установленных настоящим ТЗ.
обеспечить реакцию ответственного специалиста в срок, установленный для
критического приоритета пунктом 21.2 настоящего ТЗ; при наличии признаков
61
инцидента информационной безопасности не позднее 20 минут с указанного момента,
с учётом порядка исчисления времени, установленного пунктом 21.2, начать
первичные меры по локализации и недопущению развития инцидента, включая в
зависимости от его характера ограничение доступа, изоляцию компонента,
блокирование скомпрометированной учётной записи и сохранение журналов и иных
цифровых свидетельств;
 осуществлять восстановление работоспособности и окончательное устранение
последствий в сроки, установленные приоритетом инцидента, в части реакции и
окончательного исправления — в соответствии с пунктом 21.2, в части восстановления
и допустимой потери данных — в соответствии с пунктом 14.4 настоящего ТЗ;
 обеспечивать контроль и учет действий своих работников (работников
субподрядчиков, привлекаемых к выполнению работ), имеющих доступ к программнотехническим средствам, средствам защиты информации Экосистемы, информации
ограниченного доступа Заказчика.
Применяемые меры обеспечения информационной безопасности должны
обеспечивать минимизацию рисков, связанных с возможным нарушением
конфиденциальности, целостности и доступности информации, содержащейся в
Экосистеме. Они включают практические правила управления безопасностью
(организационно-административные, программные), в том числе:

управление доступом к Экосистеме, информационным ресурсам Экосистемы и
резервным копиям;
 предотвращение несанкционированного доступа извне;
 организация защиты данных средствами резервного копирования и
санкционированного восстановления, дублирования копий и организации их хранения;
 мониторинг и устранение уязвимостей в Экосистеме.
Комплекс механизмов защиты информации в Экосистеме должен обеспечивать
выполнение следующих требований:










доступ к персонализированному балансу и использованию программы лояльности
предоставляется после идентификации пользователя. Совершение гостевой покупки и
получение обязательных документов по ней не должны зависеть от регистрации или
активации личного кабинета, если иное не уточнено в ЧТЗ после обследования.
для каждого пользователя должна иметься возможность разграничения доступа к
компонентам Экосистемы;
для каждого пользователя должна иметься возможность установить уровень доступа,
обеспечивающий только просмотр или модификацию информации;
вход (выход) пользователей в Экосистему (из Экосистемы) должен регистрироваться в
журнале, при этом должны фиксироваться следующие данные:
 дата и время входа (выхода) пользователей в Экосистему (из Экосистемы);
 данные учетной записи, зарегистрированной при запросе доступа;
 результат попытки входа: успешная или неуспешная (несанкционированная);
должно осуществляться ведение журнала действий пользователей.
многофакторная аутентификация администраторов;
отдельный доступ к средам;
журналирование привилегированных действий;
регулярный пересмотр прав;
запрет общих неидентифицируемых учетных записей, кроме технически
обоснованных сервисных записей;
62
Защита информации в Экосистеме должна быть реализована с учетом требований
нормативных правовых актов, указанных в Приложении № 5, действующих на дату сдачиприемки результатов работ по Контракту.





учетные данные, ключи и иные секреты не размещаются в исходном коде и журналах
и хранятся в предназначенном для этого защищенном средстве;
события безопасности, попытки входа, административные действия и ошибки
интеграций журналируются в объеме, достаточном для расследования, без
избыточного включения персональных данных;
Подрядчик контролирует доступ своих работников и субподрядчиков, прекращает его
при утрате необходимости и передает Заказчику подтверждение отключения
временных учетных записей;
при выявлении инцидента Подрядчик уведомляет Заказчика и выполняет
локализацию, устранение последствий и анализ причин в порядке и сроки,
установленные Контрактом и регламентом реагирования;
должны быть предусмотрены меры против повторного начисления баллов, подмены
результатов, повторного использования идентификаторов и иных злоупотреблений в
платежных, билетных, игровых и бонусных сценариях.
Информация ограниченного доступа, полученная от Заказчика для выполнения
Работ, используется только в целях исполнения Контракта и не передается третьим лицам
без законного основания и согласования с Заказчиком.
15.3 Требования к обеспечению безопасности разработки исходного кода ПО системы
Хранение исходного кода и инфраструктурных конфигураций осуществляется в
закрытом экземпляре хранилища кода, размещённом в согласованной российской
облачной инфраструктуре и находящемся под полным административным контролем
Заказчика.
Доступ к хранилищу кода предоставляется по именным учётным записям с
многофакторной аутентификацией, разграничением ролей и журналированием
административных действий. Подключение административных и иных
привилегированных пользователей осуществляется через защищённый канал или VPN.
Публичный анонимный доступ к репозиториям запрещается.
Репозитории резервируются отдельно от основной промышленной среды. Отказ
или прекращение обслуживания основного облачного проекта не должны приводить к
одновременной утрате исходного кода, истории изменений и инфраструктурных
конфигураций.
Требования, установленные для государственных информационных систем,
применяются только в случае, если по результатам пункта 15.1 установлено правовое
основание для отнесения Экосистемы или её отдельного компонента к государственной
информационной системе. Класс защиты, уровень защищённости и состав обязательных
мер определяются по результатам обследования и применимых нормативных требований
и утверждаются Заказчиком в составе требований к защите информации.Подрядчик
обязан создать, контролировать и сопровождать библиотеку разработки ПО для
обеспечения упорядоченной разработки и последующей поддержки ПО. Библиотека
разработки ПО может быть частью среды разработки ПО и среды верификации.
63
Подрядчик должен сопровождать библиотеку разработки ПО до исполнения обязательств
по Контракту в соответствии с его условиями.
При разработке исходного кода Подрядчик должен применять методы безопасного
программирования, включающие:













ручную и автоматизированную проверку кода на предмет отсутствия
недекларированных возможностей и уязвимостей в исходном коде;
контроль версионности исходного кода;
устранение выявленных Заказчиком уязвимостей Экосистемы.
моделирование угроз для критических функций;
проверка значимых изменений;
автоматизированный статический анализ, анализ сторонних зависимостей;
динамическое тестирование и динамическая проверка применимых веб-интерфейсов и
API;
моделирование угроз для критических функций и проверка разграничения доступа;
устранение применимых уязвимостей, включая XSS, CSRF, SQL-инъекции, IDOR и
обход авторизации;
управление секретами вне исходного кода и журналов;
ведение перечня сторонних программных компонентов, их версий и лицензий;
проверка релизной сборки перед выпуском и запрет включения в нее тестовых
учетных данных, секретов и отладочных интерфейсов;
документирование выявленных уязвимостей, принятых мер и остаточного риска.
Предотвращение появления и устранение уязвимостей ПО должно быть достигнуто
путем реализации Подрядчиком мер по разработке безопасного ПО, представленных в
ГОСТ Р 56939-2024. Национальный стандарт Российской Федерации. «Защита
информации. Разработка безопасного программного обеспечения. Общие требования»
(утвержден Приказом Росстандарта от 24.10.2024 N 1504-ст "Об утверждении
национального стандарта Российской Федерации").
Требования к размещению среды разработки, аттестации, применению
сертифицированных средств защиты и лицензируемым работам устанавливаются только
при подтвержденной применимости соответствующего правового режима.
До начала применения исходного кода в Экосистеме Заказчиком может
проводиться выявление (поиск) уязвимостей, связанных с ошибками исходного кода.
Для выявления (поиска) уязвимостей могут применяться средства анализа
(контроля) защищенности (сканеры безопасности), имеющие стандартизованные
(унифицированные) в соответствии с национальными стандартами описание и перечни
программно-аппаратных платформ, уязвимостей ПО, ошибочных конфигураций, правила
описания уязвимостей, проверочные списки, процедур тестирования и языка тестирования
Экосистемы на наличие уязвимостей, оценка последствий уязвимостей, имеющие
возможность оперативного обновления БД выявляемых уязвимостей.
64
Требование
Обязательность
Критерий приемки
HTTPS/TLS
обязательно
все публичные и пользовательские
контуры работают по
защищенному соединению
Защита от
XSS/CSRF/SQLi/IDOR
обязательно
критические и высокие
уязвимости устранены
Управление секретами
обязательно
секреты отсутствуют в исходном
коде, документации и журналах
Разграничение прав
обязательно
административные роли и права
описаны и проверены
Проверка
зависимостей
обязательно для релизных
сборок
передан отчет SCA или
аналогичный отчет
SBOM
обязательно к
окончательной приемке
передан перечень сторонних
компонентов, лицензий и версий
OWASP ASVS
применяется как ориентир отчет содержит перечень
проверки веб-приложения проверенных классов требований
15.4. Персональные данные и согласия
Работа с персональными данными и их защита должна вестись в соответствии с
требованиями законодательства Российской Федерации и применимыми нормативными
правовыми актами в области защиты информации, указанными в Приложении № 5,
включая:








минимизация состава данных;
определенные цели обработки и сроки хранения;
разделение обязательных сервисных операций и маркетинговых коммуникаций;
фиксация версии согласия, даты, времени, источника и действия пользователя;
ограничение передачи данных между продуктами целями и правовыми основаниями;
обезличивание аналитики и внутренних технических инцидентов, где персональные
данные не требуются;
реализация применимых запросов субъекта персональных данных;
локализация и размещение данных в соответствии с законодательством.
15.4.1. Документирование процессов обработки персональных данных
До начала промышленной обработки персональных данных Подрядчик обязан
уточнить и передать Заказчику реестр процессов обработки персональных данных и
матрицу согласий в составе, установленном настоящим разделом.
Для каждого процесса в реестре указываются:






цель обработки;
категория субъектов;
состав персональных данных;
правовое основание;
источник получения;
информационные системы;
65









операции с данными;
получатели;
лица, обрабатывающие данные по поручению;
наличие трансграничной передачи;
срок обработки и хранения;
условие прекращения обработки;
способ блокирования, удаления или уничтожения;
ответственный владелец процесса;
применяемые меры защиты.
Подрядчик обязан обеспечить раздельное управление:





обязательными сервисными операциями;
маркетинговыми коммуникациями;
аналитическими и персонализационными сценариями;
публикацией данных;
обработкой данных несовершеннолетних, если она предусмотрена.
Отказ от маркетинговых коммуникаций не должен блокировать регистрацию,
получение билета, выполнение заказа, получение кассового чека или иных обязательных
сервисных сообщений.
Если Подрядчик или привлеченное им лицо получает доступ к персональным
данным по поручению Заказчика, соответствующие обязательства должны включать:









перечень данных и операций;
цели обработки;
обязанность соблюдать конфиденциальность;
требования к защите;
порядок привлечения субподрядчиков;
сроки уведомления об инциденте;
предоставление подтверждающих документов;
прекращение доступа;
возврат или уничтожение данных после завершения Работ.
15.4.2. Приемка требований к персональным данным
До ввода в промышленную эксплуатацию Подрядчик передает:
Документ/результат
Минимальное содержание
Реестр процессов
обработки
Цели, данные, основания, системы, получатели, сроки
Матрица согласий
Вид согласия, версия текста, канал, способ подтверждения, отзыв
Матрица хранения и
удаления
Сущность, система, срок, основание, действие после окончания
Реестр внешних
обработчиков
Организация, сервис, данные, цель, территория размещения
Карта потоков ПДн
Источник, получатель, канал, правовое основание
Порядок реализации
прав субъекта
Доступ, уточнение, блокирование, отзыв, удаление
Протокол проверок
Регистрация согласия, отзыв, прекращение рассылки, удаление
66
Документ/результат
Минимальное содержание
Отозваны временные и более не требующиеся доступы
Подрядчика и субподрядчиков. Для продолжающихся работ и
сопровождения сохранены только согласованные именные
Актуализация и
учётные записи с необходимыми полномочиями. Подтверждены
прекращение доступов
реестр доступов, сроки их действия и порядок окончательного
отзыва.
15.5 Требования к оплате и фискализации
Ввод и обработка полных реквизитов банковских карт должны выполняться на
стороне платежного провайдера либо с применением предоставленных им защищенных
платежных компонентов.
Экосистема не должна хранить:





полный номер банковской карты;
код проверки подлинности карты;
PIN-код;
данные магнитной полосы;
иные аутентификационные данные платежного средства.
Экосистема вправе хранить только сведения, необходимые для идентификации и
сверки операции:









внутренний идентификатор заказа;
идентификатор платежа у платежного провайдера;
сумму и валюту;
дату и время;
статус платежа;
способ оплаты в допустимом обезличенном виде;
маскированное представление платежного инструмента при необходимости;
сведения о возврате;
идентификатор кассового чека.
Должны поддерживаться следующие состояния платежной операции:










создан;
ожидает оплаты;
обрабатывается;
успешно завершен;
отклонен;
отменен;
истек;
частично возвращен;
полностью возвращен;
требует сверки.
Уведомления платежного провайдера должны:


проверяться на подлинность;
обрабатываться идемпотентно;
67




журналироваться без платежных секретов;
сопоставляться с заказом;
не допускать повторной оплаты либо повторного исполнения заказа;
поддерживать повторное получение фактического статуса.
Экосистема должна обеспечивать прослеживаемую связь: заказ → платеж →
кассовый чек → возврат → чек возврата.

В части компонентов и интеграций, изменяемых Подрядчиком, а также при проверке
сохранения работоспособности существующего торгового контура должны
обеспечиваться следующие сквозные результаты:передача необходимых сведений в
ККТ/ОФД;
 формирование кассового чека и чека возврата;
 получение и хранение статуса фискализации;
 направление электронного чека пользователю установленным способом;
 повторное получение или направление чека;
 обработка частичного возврата;
 сверка заказов, платежей и фискальных документов;
 журналирование ошибок фискализации;
 повторная передача данных после временной недоступности внешнего сервиса.
Настоящий пункт не возлагает на Подрядчика обязанность по замене или развитию
существующей внутренней логики 1С, эквайринга, ККТ и ОФД, если такие работы прямо
не установлены настоящим ТЗ. Подрядчик отвечает за разработанные или изменённые им
компоненты, интеграции и настройки, а также за восстановление функций торгового
контура, нарушенных вследствие его действий.
Недоступность аналитики, CRM или программы лояльности не должна
блокировать законное завершение оплаты и фискализации.
15.6. Приемка безопасности
Базовая безопасность является обязательным условием приемки. До ввода в
промышленную эксплуатацию должны быть устранены все критические и высокие
уязвимости, выявленные в пределах согласованной проверки безопасности.
Средние уязвимости могут быть приняты только по письменному решению Заказчика при
наличии оценки риска, компенсирующих мер, ответственного и срока устранения.
На этапах 1 и 2 Подрядчик собственными силами проводит проверки
информационной безопасности публикуемых компонентов и интеграций по
согласованной программе. До публичного запуска соответствующего выпуска
устраняются выявленные критические и высокие уязвимости; остальные результаты
рассматриваются в порядке, установленном настоящим пунктом.
В составе этапа 3 Подрядчик за свой счёт обеспечивает независимый аудит
информационной безопасности Экосистемы с привлечением третьего лица, не
участвовавшего в разработке, внедрении и сопровождении проверяемых компонентов.
Независимый аудит и подтверждение устранения выявленных несоответствий
выполняются к КТ-8.
Привлечённое лицо должно обладать необходимыми специалистами, знаниями и
техническими средствами для выполнения предусмотренных настоящим ТЗ проверок.
Если отдельные работы, включённые в состав аудита, в соответствии с законодательством
68
Российской Федерации относятся к лицензируемым видам деятельности, лицо,
непосредственно выполняющее такие работы, должно иметь соответствующую
действующую лицензию.
До начала аудита Подрядчик представляет Заказчику сведения о привлекаемом
лице, составе исполнителей, опыте выполнения сопоставимых работ, программе,
методике и границах проверки. Программа и методика проведения аудита подлежат
согласованию с Заказчиком.
Подрядчик передает программу и результаты проверки безопасности, перечень
выявленных уязвимостей и подтверждение повторной проверки после их устранения.
Заказчик вправе провести либо привлечь независимую экспертизу в порядке,
установленном Контрактом.
15.7. Пользовательские юридические документы и правовые тексты
Подрядчик обязан обеспечить силами привлечённого в состав команды юриста или
юристов разработку полного комплекта пользовательских юридических документов и
юридически значимых интерфейсных текстов, необходимых для законной эксплуатации
Экосистемы и реализации предусмотренных настоящим ТЗ пользовательских сценариев.
Подготовка, согласование и размещение пользовательских юридических
документов выполняются поэтапно. До публичного запуска каждого этапа должны быть
утверждены и размещены документы и интерфейсные тексты, применимые к вводимым
пользовательским сценариям.
На этапе 1 Подрядчик проверяет документы действующих продуктов и при
необходимости адаптирует их к фактически реализованным процессам. На этапе 2
комплект дополняется документами для единой идентификации, личного кабинета, CRM,
программы лояльности, мобильного приложения и иных вводимых функций. На этапе 3
обеспечиваются дополнения для окончательного состава Экосистемы и передача полного
актуального комплекта.
Языковые версии юридических документов предоставляются одновременно с
соответствующими языковыми версиями пользовательского интерфейса.
Требование распространяется на основной сайт, сайт Фонда, единый личный
кабинет, мобильное приложение, программу лояльности, формы обращений и подписок,
сервисы пожертвований и волонтёрства, а также на интернет-магазин, билетные,
платёжные и иные внешние сервисы в части пользовательских интерфейсов, переходов и
процессов, разрабатываемых или изменяемых Подрядчиком.
Подготовка пользовательских юридических документов входит в состав Работ и не
может быть отнесена Подрядчиком к подготовке контента Заказчиком. Заказчик
предоставляет Подрядчику достоверные сведения об организации, реквизиты, сведения о
применяемых процессах, внутренних решениях, владельцах сервисов и иные фактические
данные, необходимые для разработки документов. Правовой анализ, подготовка проектов
документов, их согласование между собой и адаптация к фактически реализованным
пользовательским сценариям осуществляются Подрядчиком.
До подготовки юридических документов Подрядчик обязан провести
инвентаризацию всех пользовательских сценариев, при которых:
69

осуществляется сбор, запись, хранение, использование, передача или удаление
персональных данных;
 пользователь предоставляет согласие, принимает условия, совершает юридически
значимое действие либо отзывает ранее предоставленное согласие;
 осуществляется регистрация, авторизация, оформление заказа, приобретение или
возврат билета или товара, пожертвование, участие в программе лояльности, подписка,
направление обращения или предоставление пользовательского материала;
 применяются файлы cookie, метрические, аналитические, рекламные,
персонализационные или иные средства отслеживания;
 используются внешние сервисы, виджеты, платёжные системы, билетные операторы
или иные лица, получающие пользовательские данные.
По результатам инвентаризации Подрядчик формирует и согласовывает с
Заказчиком реестр пользовательских юридических документов и юридически значимых
интерфейсных текстов.
Комплект должен включать в применимой к реализованным сценариям части не
менее:



политики в отношении обработки персональных данных пользователей Экосистемы;
пользовательского соглашения сайта, личного кабинета и мобильного приложения;
согласий на обработку персональных данных, разделённых по целям обработки,
категориям данных, каналам и пользовательским сценариям;
 отдельного согласия на получение рекламных и маркетинговых сообщений;
 документов и уведомлений, регулирующих использование файлов cookie,
метрических, аналитических, рекламных и персонализационных технологий;
 правил программы лояльности, включая порядок участия, начисления, списания,
отмены, возврата, истечения баллов, изменения правил и прекращения участия;
 условий приобретения, использования, отмены и возврата билетов, а также сведений о
лице, реализующем билеты, и распределении ответственности между Музеем и
билетным оператором;
 публичных оферт, правил оплаты, доставки, отмены и возврата товаров, работ или
услуг в части торговых и платёжных сценариев, входящих в Экосистему;
 документов, регулирующих волонтёрские, партнёрские и иные предусмотренные
сайтом инициативы;
 документов и согласий, необходимых для создания и использования связанных
детских профилей и обработки данных несовершеннолетних, если такие сценарии
реализуются;
 обязательных сведений о Заказчике, правообладателях, продавцах, исполнителях
услуг, платёжных, билетных и иных привлечённых организациях;
 текстов чекбоксов, подписей форм, предупреждений, уведомлений, пояснений,
подтверждений, ссылок, сообщений об отзыве согласия и иных юридически значимых
элементов пользовательского интерфейса.
Перечень является минимальным. Подрядчик обязан включить в комплект иные
пользовательские юридические документы и тексты, необходимость которых следует из
законодательства Российской Федерации, фактически реализованной функциональности,
состава обрабатываемых данных или используемых внешних сервисов.
70
Использование типовых, шаблонных или заимствованных документов без их
проверки и адаптации к архитектуре, процессам, составу данных, ролям участников и
пользовательским сценариям Экосистемы не допускается.
Для каждого документа или юридически значимого текста в реестре указываются:







наименование и назначение;
применимый компонент и пользовательский сценарий;
пользовательская аудитория;
правовое основание;
ответственное лицо или организация;
место размещения и способ предоставления пользователю;
действие пользователя, подтверждающее принятие условий или предоставление
согласия;
 порядок отзыва, изменения или прекращения действия;
 номер версии, дата утверждения и дата начала применения;
 системы, в которых фиксируется факт принятия, версия текста, дата, время, источник
и действие пользователя.
Согласия на рекламные и маркетинговые коммуникации должны предоставляться
отдельно от принятия обязательных условий использования сервисов. Отказ от таких
согласий не должен препятствовать регистрации, приобретению билета или товара,
получению кассового чека, использованию личного кабинета и получению обязательных
сервисных уведомлений.
Чекбоксы предоставления согласия или принятия условий не должны быть
предварительно отмечены, если иной способ прямо не допускается применимым
законодательством. Пользователю до совершения действия должна быть доступна полная
редакция соответствующего документа.
Подрядчик обязан обеспечить размещение утверждённых документов и текстов во
всех применимых пользовательских интерфейсах, настроить ссылки, чекбоксы и иные
механизмы принятия и отзыва, а также обеспечить фиксацию и хранение версии текста,
принятой конкретным пользователем, в соответствии с пунктами 9.3 и 15.4 настоящего
ТЗ.
Юридические документы должны быть доступны для просмотра без авторизации,
если их назначение не требует иного, иметь постоянные адреса, дату и номер версии,
поддерживать архив предыдущих редакций и редактироваться уполномоченными
сотрудниками Заказчика через систему управления содержанием без изменения
программного кода.
Для русской и английской версий пользовательских интерфейсов Подрядчик
обеспечивает подготовку и размещение согласованных языковых версий юридических
документов и текстов. Английская версия должна соответствовать утверждённой русской
редакции. При отсутствии отдельно установленного правового режима приоритет имеет
русская версия, о чём пользователь должен быть проинформирован.
Проекты документов передаются на проверку юристам Заказчика. Подрядчик
обязан устранить замечания и обеспечить взаимную согласованность документов,
интерфейсных текстов и фактически реализованных процессов. Окончательные редакции
утверждаются Заказчиком в письменной форме.
71
Согласование документов Заказчиком не освобождает Подрядчика от обязанности
устранить выявленные несоответствия, противоречия и пропуски, возникшие вследствие
ненадлежащего правового анализа, подготовки или технической реализации со стороны
Подрядчика.
Без письменного утверждения Заказчиком применимого юридического документа
соответствующий пользовательский сценарий не считается готовым к промышленной
эксплуатации и не подлежит приёмке.
До итоговой приёмки Подрядчик передаёт Заказчику:




реестр пользовательских юридических документов и текстов;
окончательные утверждённые редакции в редактируемом формате;
тексты, размещённые в системе управления содержанием;
таблицу соответствия документов пользовательским сценариям, формам и
интерфейсам;
 историю версий и архив ранее применявшихся редакций;
 протокол проверки размещения, принятия, фиксации версии, отзыва согласий и
прекращения маркетинговых коммуникаций.
Заказчик вправе использовать, изменять, публиковать и передавать для
последующей доработки третьим лицам подготовленные в рамках Контракта документы и
тексты без дополнительного согласия Подрядчика и без дополнительной оплаты.
16. Организация выполнения Работ
16.1. Команда Подрядчика
Подрядчик самостоятельно формирует команду, достаточную для выполнения
Работ, и назначает ответственных за управление проектом, архитектуру, анализ
требований, разработку, дизайн, интеграции, тестирование, информационную
безопасность, правовое обеспечение пользовательского контура, эксплуатацию и
документацию. Совмещение ролей допускается при сохранении необходимой
квалификации, независимости проверок и ответственности за результат.
Замена ключевого специалиста допускается на специалиста не ниже заявленной
квалификации с уведомлением Заказчика и передачей знаний без влияния на сроки.
16.2. Проектная система
Задачи, дефекты, решения, риски, блокировки, вопросы и изменения фиксируются
в единой проектной системе, доступной Заказчику.
Инструмент
Реестр работ
Доска статусов
Еженедельный отчет
Демонстрация
Реестр решений
Реестр рисков
Обязательное содержание
Требования, задачи, дефекты, документы, риски и
зависимости
Backlog, Ready, In progress, Review, QA/UAT, Blocked,
Accepted, Released либо эквивалент
Выполнено, в работе, на приемке, блокировки, риски,
решения и план
Работающий результат на тестовой среде по согласованному
сценарию
Контекст, варианты, решение, последствия, дата и
ответственный
Вероятность, влияние, владелец, меры и статус
72
Инструмент
Запрос на изменение
Обязательное содержание
Причина, состав, влияние на сроки, цену, архитектуру,
документы и приемку, все изменения, влияющие на объем
контракта и допустимые в рамках 44-ФЗ, оформляются
дополнительными соглашениями
16.3. Взаимодействие с другими подрядчиками
Подрядчик обязан участвовать в совместных технических сессиях, предоставлять
тестовые данные, анализировать журналы, фиксировать границы ответственности и не
ограничиваться утверждением «ошибка на стороне другой системы» без
воспроизводимых доказательств.
17. Календарный план и контрольные точки выполнения Работ
17.1. Общая модель выполнения работ
Контракт предусматривает четыре самостоятельных этапа: декабрьский запуск,
майский запуск, запуск Экосистемы и стабилизация Экосистемы. Каждый этап имеет
определённый настоящим техническим заданием и Контрактом результат.
Календарный план содержит контрольные точки внутри этапов, используемые для
управления проектом, демонстрации и согласования промежуточных результатов и сами
по себе не являются основанием для оплаты. Основанием для оплаты является
подписанный Заказчиком документ о приёмке соответствующего этапа, включая
выполненные, предусмотренные настоящим Техническим заданием испытания и
переданные Заказчику вместе с исходными кодами, данными, документацией, правами,
доступами и иными результатами работ.
Контрольные точки не являются самостоятельными этапами исполнения Контракта
в смысле части 1 статьи 3 и статьи 94 Федерального закона № 44-ФЗ, не влекут отдельной
приемки, оформления документа о приемке и оплаты. Согласование промежуточного
результата не освобождает Подрядчика от ответственности за соответствие итогового
результата технического заданияПромежуточные результаты рассматриваются
Заказчиком на демонстрациях и оформляются протоколами. Подписание таких
протоколов не означает окончательной приёмки соответствующей части Экосистемы и не
освобождает Исполнителя от устранения выявленных в дальнейшем несоответствий
требованиям настоящего Технического задания.
Этапы 1 и 2 завершаются промышленным запуском и передачей пригодного к
самостоятельному использованию результата. Дальнейшая разработка ведётся с
сохранением работы опубликованных сервисов.
До приёмки соответствующего этапа отдельные его результаты могут по решению
Заказчика допускаться к опытной эксплуатации на основании акта допуска. Такой акт сам
по себе не заменяет документ о приёмке этапа и не является основанием для его оплаты.
Прекращение указанной опытной эксплуатации производится по требованию Заказчика.
Данное положение не изменяет статус результатов этапов 1 и 2, принятых по
отдельным документам о приёмке и введённых в промышленную эксплуатацию.
Приёмка этапов 1 и 2 не отменяет обязательств Подрядчика по совместимости,
последующей интеграции и достижению полного результата этапа 3.
73
Комплексы работ являются технологической детализацией четырёх этапов. Один
комплекс может выполняться в нескольких этапах; состав сдаваемой части и её стоимость
относятся к конкретному этапу один раз.
Промежуточные демонстрации оформляются протоколами. Протокол контрольной
точки не заменяет документ о приёмке этапа.
74
17.2. Календарный план и этапы
17.2.1 Этапы
Этап
Этап 1
Декабрьский
запуск
Этап 2
Майский запуск
Этап 3
Запуск
Экосистемы
Этап 4
Стабилизация
экосистемы
Срок выполнения
работ
Принимаемый результат
С даты заключения
контракта до 20.12.2026
Русскоязычный основной сайт: главная страница, афиша и страницы событий, новости,
страницы всех филиалов, справочные сведения, действующий билетный контур, CMS,
применимые официальные и юридические страницы. Редизайн действующего интернетмагазина с сохранением его авторизации, личного кабинета и торговых сценариев. Базовая
аналитика, инфраструктура и эксплуатационные средства, нагрузка по пункту 14.1.1,
проверки силами Подрядчика, обучение и передача результатов.
С даты приемки этапа 1
до 31.05.2027
Полный основной сайт с поиском, сайт Фонда на общей CMS, витрина коллекции; единые
SSO и ЛК, CRM, лояльность, уведомления, аналитика и интеграции. RU/EN-интерфейсы
вводимых продуктов. Миграция и привязка к единому профилю покупок начиная с
публичного запуска этапа 1. Проверки выпуска силами Подрядчика, обучение и передача
результатов.
C даты приемки 2 этапа
до 01.11.2027
Весь обязательный объём ТЗ, включая готовые контентные продукты по пункту 9.10.12.
Комплексные испытания, независимые аудиты информационной безопасности и цифровой
доступности, опытная эксплуатация по пункту 18.6, полная передача исходников, прав,
документации, доступов и знаний.
90 календарных дней с
даты приёмки этапа 3
Усиленный мониторинг, круглосуточное реагирование на критические инциденты,
диагностика, консультации и сопровождение обновлений в установленном объёме.
Отчётность, актуальные эксплуатационные материалы и передача сопровождения.
Отдельная приёмка и оплата.
Календарный план Подрядчика должен обеспечивать выполнение всех предшествующих работ, проверок и процедур публикации к
установленным срокам соответствующих этапов. Относительный срок контрольной точки не является основанием для переноса календарной
75
даты завершения этапа. Результаты, необходимые для более раннего публичного запуска, предоставляются в объёме соответствующего
выпуска до такого запуска.
Согласование детализированного календарного плана само по себе не изменяет сроки исполнения Контракта.
17.2.2 Календарный план
№
1
2
Период
1–20-й
календарны
й день
10–40-й
календарны
й день
Комплекс работ
Основные результаты и контрольная точка
Инициация
проекта и
обследование
Утверждены план управления проектом, порядок взаимодействия, состав проектной
команды, матрица ответственности; сформированы реестр исходных систем и
интеграций, перечень необходимых доступов, реестр рисков и зависимостей. Проведено
обследование основного сайта, сайта Фонда, интернет-магазина, мобильного приложения,
билетной системы, CRM, музейной учётной системы и иных интегрируемых систем.
Проведена инвентаризация пользовательских юридически значимых сценариев и
сформирован реестр документов и исходных сведений в соответствии с пунктом 15.7
настоящего ТЗ. Контрольная точка КТ-1
Проектирование
архитектуры,
данных,
интерфейсов и
пользовательских
сценариев;
развёртывание
технологического
контура
Согласованы целевая архитектура Экосистемы, модель единой учётной записи, схема
данных и интеграций, программные интерфейсы интеграций и личного кабинета, правила
миграции и слияния учётных записей, прототипы ключевых пользовательских сценариев,
дизайн-система и комплект макетов основного сайта, интернет-магазина и мобильного
приложения, планы испытаний, миграции и аналитики, реестр процессов обработки
персональных данных, регламент опытной эксплуатации, архитектура серверной
доставки контентных продуктов. Развёрнуты технологические среды в соответствии с
пунктом 12.2 настоящего ТЗ, репозиторий, конвейер сборки, мониторинг и
журналирование. Определены сценарии игровых, AR- и аудиоматериалов. Контрольная
точка КТ-2
76
№
3
3а
3b
Период
30–120-й
календарны
й день
Комплекс работ
Основные результаты и контрольная точка
Разработка
общего вебконтура
Разработаны общее ядро Экосистемы и общая система управления содержанием;
реализованы основной сайт и сайт Фонда; обеспечены адаптивность, поиск, навигация,
формы, управление содержанием, роли администраторов, базовая аналитика и
техническая доступность интерфейсов; реализован механизм локализации в соответствии
с пунктом 13.6 настоящего ТЗ; реализована витрина коллекции с получением данных из
музейной учётной системы по программному интерфейсу. Сайт Фонда перенесён на
общую CMS с сохранением согласованных внешнего вида и пользовательского
поведения. Выполнена тестовая миграция материалов. Контрольная точка КТ-3
Подготовка и
публичный
запуск этапа 1
Опубликованы основной сайт и обновлённый интернет-магазин в составе этапа 1.
Проведены применимые функциональные, интеграционные, нагрузочные проверки,
проверки безопасности, цифровой доступности, резервного восстановления и отката
силами Подрядчика. Проверены торговые сценарии и сервисные уведомления. Настроены
мониторинг и резервное копирование, утверждены и размещены применимые
юридические документы, проведено обучение, передан комплект результатов этапа.
Контрольная точка КТ-Д.
Эксплуатация
введенных
продуктов до
приемки этапа 3
Продукты этапа 1 развёрнуты в промышленной среде. Ведутся журналы событий,
обращений и дефектов; критические и существенные дефекты устранены.
Состав
этапа 1 —
до КТ-Д
По мере
готовности
компоненто
в этапа 1, до
КТ-Д.
От КТ-Д
до КТ-10
77
№
4
5
6
Период
100–150-й
календарны
й день
50–180-й
календарны
й день
80–240-й
календарны
й день
Комплекс работ
Основные результаты и контрольная точка
Испытания,
наполнение и
подготовка
полного вебконтура этапа 2
Веб-контур прошёл функциональные, интеграционные и регрессионные испытания;
проведены независимые проверки информационной безопасности и цифровой
доступности публикуемой части по согласованным с Заказчиком программам,
уязвимости критического и высокого уровня устранены; выполнены итоговая миграция и
наполнение материалами; обучены редакторы Заказчика, переданы инструкции и порядок
обращения по инцидентам; обеспечены сохранение работоспособной копии
действующего сайта и порядок возврата к ней. Публичный ввод результатов этапа 2
выполняется в срок, установленный пунктом 17.2.1. Контрольная точка КТ-4
Разработка
личного
кабинета,
программы
лояльности и
интеграционного
контура
Реализованы регистрация и авторизация, единый профиль посетителя, личный кабинет,
билеты и QR-коды, история покупок и заказов, обращения, программа лояльности,
уведомления и настройки согласий. Выполнены интеграции с билетной системой по
программному интерфейсу, CRM, музейной учётной системой, интернет-магазином и
учётной системой 1С, аналитическими системами и иными предусмотренными ТЗ
сервисами. Выполнена адаптация интернет-магазина в пределах установленной зоны
ответственности Исполнителя. Контрольная точка КТ-5
Разработка
мобильных
приложений
Разработаны приложения для поддерживаемых версий iOS и Android, реализованы
единая авторизация, личный кабинет, билеты, программа лояльности, уведомления и
предусмотренные мобильные сценарии; подписанные сборки-кандидаты
продемонстрированы на устройствах и переданы на публикацию. Согласованы с
Заказчиком аудиторы, программы и методики независимых аудитов. Контрольная точка
КТ-6
78
№
7
8
9
Период
40–275-й
календарны
й день
240–310-й
календарны
й день
311–340-й
календарны
й день
Комплекс работ
Основные результаты и контрольная точка
Производство и
публикация
цифровых
контентных
продуктов
Подготовлен обязательный объём игровых маршрутов, AR-маршрутов и аудиогидов,
установленный пунктом 9.10.12 настоящего ТЗ, включая сценарии, графические,
звуковые и мультимедийные материалы; продукты проверены на площадках Музея,
замечания Заказчика устранены; публикация выполнена механизмом серверной доставки
— материалы доступны в приложении без выпуска новой сборки. Подготовлен,
утверждён Заказчиком, размещён и проверен комплект пользовательских юридических
документов и текстов в соответствии с пунктом 15.7 настоящего ТЗ. Контрольная точка
КТ-7
Комплексные
испытания,
аудиты и
подготовка
Экосистемы к
опытной
эксплуатации
Проведены функциональные, интеграционные, нагрузочные (в соответствии с пунктом
14.1.1), регрессионные испытания и проверка сквозных пользовательских сценариев,
проверены резервное копирование и восстановление, журналирование, мониторинг и
выпуск версий, продемонстрирован третий язык интерфейса. Проведены независимые
аудиты информационной безопасности и цифровой доступности Экосистемы, устранены
выявленные несоответствия. Выполнены итоговая миграция и сверка данных. Мобильные
приложения опубликованы в магазинах приложений. Передан предварительный комплект
документации, проведено обучение сотрудников Заказчика. Контрольная точка КТ-8
Опытная
эксплуатация
Экосистемы
Экосистема развёрнута в промышленной среде в полном составе. Проведена опытная
эксплуатация продолжительностью 720 часов в порядке, установленном пунктом 18.6
настоящего ТЗ. Ведутся журналы событий, обращений и дефектов; критические и
существенные дефекты устранены. Оформлен протокол завершения опытной
эксплуатации. Контрольная точка КТ-9
79
№
10
11
Период
Комплекс работ
Основные результаты и контрольная точка
341–365-й
календарны
й день
Итоговая
приёмка и
передача
Экосистемы
Проведены итоговые приёмочные испытания. Заказчику передан полный комплект
результатов, документов, исходных материалов, учётных записей, прав и лицензий в
соответствии с разделами 19 и 20 настоящего ТЗ. После устранения замечаний и
выполнения всех условий приёмки подписывается документ о приёмке этапа 3.
Контрольная точка КТ-10
Стабилизация
после запуска
Исполнитель осуществляет усиленный мониторинг Экосистемы, обрабатывает
обращения, устраняет выявленные дефекты, консультирует сотрудников Заказчика и
обеспечивает сопровождение первых обновлений. Режим, содержание и
продолжительность стабилизации определяются пунктом 21.2 настоящего ТЗ.
Стабилизация является самостоятельным оплачиваемым этапом 4. Её содержание и
режим определяются пунктом 21.2, комплект приёмки — пунктом 18.5. Исправление
собственных гарантийных дефектов не предъявляется к дополнительной оплате.
В течение
этапа 4 по п.
17.2.1
80
17.3. Контрольные точки
Устанавливаются следующие контрольные точки. Предельный срок выполнения
контрольной точки исчисляется в календарных днях с даты заключения Контракта.
Контрольн
ая точка
Предельный срок
Подтверждаемый результат
КТ-1
20-й день
Завершено обследование, утверждены порядок
выполнения работ и матрица ответственности;
сформирован реестр запрошенных и полученных
доступов, непредоставленные доступы
зафиксированы в отчёте по контрольной точке
КТ-2
40-й день
Согласованы архитектура, прототипы, дизайнсистема и комплект макетов основного сайта,
интернет-магазина и мобильного приложения,
модель данных, программные интерфейсы
интеграций и единого личного кабинета, реестр
процессов обработки персональных данных,
регламент опытной эксплуатации; развёрнуты
технологические среды по пункту 12.2,
репозиторий, конвейер сборки, мониторинг и
журналирование; определены сценарии контентных
продуктов
КТ-Д
20 декабря 2026
Выполнен и запущен этап 1 в полном объеме по п.
17.2.1 и готовность комплекта приёмки по п. 18.5.
КТ-3
120-й день
Готовы основной сайт, сайт Фонда, общее ядро
CMS, механизм локализации и витрина коллекции с
получением данных из музейной учётной системы в
испытательной среде; выполнена тестовая миграция
КТ-4
150-й день
Готовность веб-контура этапа 2 в испытательной
среде: пройдены функциональные, интеграционные
и регрессионные испытания; проведены
независимые проверки информационной
безопасности и цифровой доступности публикуемой
части, уязвимости критического и высокого уровня
устранены; выполнены тестовая миграция и
наполнение материалами основного сайта; обучены
редакторы; обеспечены сохранение
работоспособной копии действующего сайта и
порядок возврата к ней. Публичный ввод
результатов этапа 2 выполняется в срок,
установленный пунктом 17.2.1.
81
Контрольн
ая точка
Предельный срок
Подтверждаемый результат
КТ-5
180-й день
Готовы личный кабинет, программа лояльности и
интеграционный контур (билетная система по
программному интерфейсу, CRM, музейная учётная
система, интернет-магазин и 1С, аналитика) в
испытательной среде; выполнена адаптация
интернет-магазина. Замечание к одной интеграции
не препятствует согласованию остальных. Переход
покупки билетов на интеграционный сценарий
выполняется с сохранением доступности покупки и
ранее оформленных билетов
КТ-6
220-й день
Мобильные приложения готовы: подписанные
сборки-кандидаты продемонстрированы на
устройствах и переданы на публикацию.
Согласованы с Заказчиком аудиторы, программы и
методики независимых аудитов информационной
безопасности и цифровой доступности
КТ-М
31 мая 2027
Выполнен и запущен этап 2 в полном объеме по п.
17.2.1 и готовность комплекта приёмки по п. 18.5.
КТ-7
275-й день
Контентные продукты готовы в объёме пункта
9.10.12, проверены на площадках Музея, замечания
Заказчика устранены; материалы опубликованы
механизмом серверной доставки и доступны в
приложении без выпуска новой сборки
КТ-8
310-й день
Завершены комплексные испытания, включая
нагрузочные по пункту 14.1.1, демонстрацию
третьего языка интерфейса и проверку сценариев
безопасности; проведены независимые аудиты
информационной безопасности и цифровой
доступности; выполнены итоговая миграция и
сверка данных; проверка актуальных
опубликованных версий и необходимых обновлений
мобильных приложений, опубликованых в
магазинах приложений; передан предварительный
комплект документации; проведено обучение.
Экосистема готова к опытной эксплуатации
КТ-9
340-й день
Завершена опытная эксплуатация Экосистемы
продолжительностью 720 часов в порядке,
установленном пунктом 18.6 настоящего ТЗ. При
приостановке исчисления опытной эксплуатации в
соответствии с регламентом предельные сроки КТ-9
и КТ-10 продлеваются на период приостановки
КТ-10
365-й день
Завершены итоговая приёмка и передача
Экосистемы – этап 3.
КТ-11
455-й день
Этап 4 - стабилизация успешно проведена, 90 дней
после приёмки этапа 3.
Требования к составу отчетности по контрольной точке устанавливаются в
Приложении № 4 к настоящему ТЗ.
82
Готовность единого пользовательского и интеграционного контура подтверждается
на КТ-5, готовность сборок и передача на публикацию — на КТ-6. Детализированный
календарный план предусматривает резерв на устранение замечаний магазинов
приложений и повторную подачу. Разработка серверной части, приложений, контента и
инфраструктуры выполняется параллельно по согласованному календарному плану.
Задержки внешних зависимостей и приостановки испытаний фиксируются и не
продлевают сроки автоматически.
17.4. Рассмотрение промежуточных результатов
Заказчик рассматривает представленный промежуточный результат и направляет единый
консолидированный перечень замечаний в течение пяти рабочих дней, если иной срок не
установлен протоколом рабочей встречи. Подрядчик устраняет обоснованные замечания,
связанные с несоответствием результата требованиям Технического задания,
согласованным проектным решениям и дизайн-системе.
Отсутствие замечаний к промежуточному результату не означает его
окончательной приёмки.
18. Испытания и приемка
18.1. Виды испытаний













проверка требований и документации;
функциональные испытания;
интеграционные испытания;
регрессионное тестирование;
проверка миграции и качества данных;
нагрузочное тестирование;
тестирование безопасности;
тестирование доступности;
совместимость браузеров и устройств;
тестирование резервного восстановления;
пользовательское приемочное тестирование;
опытная эксплуатация;
приемочные испытания.
18.2. Программа и методика испытаний
Подрядчик разрабатывает программу и методику испытаний на основе ТЗ и
матрицы приемки. Документ утверждается Заказчиком до проведения соответствующих
испытаний и не может исключать требования или выбирать только удобные Подрядчику
проверки.
Программа и методика испытаний должна обеспечивать трассировку:
Для каждого тестового случая указываются:




уникальный идентификатор;
проверяемые требования и сценарии;
критичность;
роли, права и каналы;
83










предусловия и исходное состояние;
тестовые данные;
действия пользователя и системы;
ожидаемые состояния интерфейса, данных и интеграций;
ожидаемые аналитические и технические события;
отрицательные проверки;
применимые проверки доступности;
способ очистки или восстановления тестовых данных;
перечень доказательств;
однозначный критерий «пройден/не пройден».
Для пользовательских сценариев проверяются состояния loading, empty, partial,
validation error, system error, success, а также истёкшее состояние и недостаточность прав
или разрешений, если они применимы.
Подрядчик не вправе заменять сквозное испытание демонстрацией отдельных
экранов, прямым изменением данных, ручным обходом штатного процесса либо
подменой интеграции тестовой заглушкой, кроме специально согласованных испытаний
отказоустойчивости.
Минимальный состав приёмочных проверок и доказательств по каждому
сквозному сценарию устанавливается Приложением № 1 к настоящему ТЗ.
18.3. Классификация дефектов
Класс
Blocker
Critical
Major
Minor
Cosmetic
Описание
Полностью блокирует критический
сценарий, приемку или запуск.
Нарушает безопасность, данные, оплату, QR,
авторизацию, ключевую интеграцию или
критический сценарий.
Нарушает обязательную функцию или
сценарий, но не приводит к последствиям
уровня Blocker или Critical
Ограниченное нарушение без влияния на
критические сценарии.
Визуальное или текстовое замечание без
влияния на функцию и доступность.
Влияние на приемку
Приемка невозможна.
Приемка невозможна.
Приёмка не
допускается, если
дефект препятствует
прохождению
обязательного сценария
или достижению
установленного
результата. В остальных
случаях принятие
возможно только по
решению Заказчика с
указанием срока
устранения
Может быть принято со
сроком устранения.
Может быть принято со
сроком устранения.
18.4 Результаты, подлежащие приемке
18.4.1 Замечания к качеству
Заказчик вправе в ходе приемки предъявлять замечания к качеству,
функциональности, дизайну и пользовательским сценариям. Замечания
84
классифицируются в соответствии с пунктом 18.3. Подрядчик обязан устранить все
замечания в согласованные сроки. Замечания устраняются за счет Подрядчика.
Дефекты Blocker и Critical подлежат обязательному устранению до приёмки.
Дефекты Major, препятствующие прохождению обязательного сценария или достижению
установленного результата, также подлежат устранению до приёмки.
Иные дефекты Major могут быть приняты только по письменному решению
Заказчика с указанием срока устранения. Дефекты Minor и Cosmetic могут быть включены
в реестр с согласованными сроками устранения.
18.4.2 Промежуточный контроль
По контрольным точкам Заказчик проверяет ход выполнения Работ, проводит
демонстрации и экспертизу промежуточных результатов. Подрядчик передает в
применимой части рабочий программный код, демо-версию, описание API, инструкции,
протоколы тестирования и актуальную проектную документацию.
Промежуточное согласование, протокол демонстрации или размещение результата
на тестовом сервере не означают приемку части Работ, не подтверждают окончательное
качество и не являются основанием для оплаты.
18.4.3 Итоговая приемка
Условия приёмки применяются к составу сдаваемого этапа. На этапе 3 проверяется
полный обязательный объём Экосистемы; на этапе 4 — результаты стабилизации.

















реализован весь обязательный объём сдаваемого этапа.;
пройдены применимые к этапу части сценариев; полный набор подтверждён на этапе
3: все сценарии С-01—С-27 выполнены в предусмотренных каналах;
для каждого сценария представлены предусмотренные доказательства;
выполнена трассировка функций, требований, тестов и дефектов;
не осталось обязательных тестовых случаев со статусом «не проверено»;
отрицательные и деградационные ветки пройдены;
проверено отсутствие повторных заказов, платежей, профилей, обращений,
начислений и уведомлений при повторной доставке запроса или события;
доступность проверена на основных состояниях сценариев, включая загрузку,
отсутствие данных, ошибку и успешный результат, устранены дефекты Blocker и
Critical;
настроены мониторинг, журналы, резервное копирование и восстановление;
проведено обучение и проверка сборки/развертывания;
передан комплект результатов сдаваемого этапа; полный комплект Экосистемы — на
этапе 3, предусмотренный разделами 19 и 20 настоящего ТЗ;
Экосистема развернута в промышленной среде;
завершены работы, отнесённые к сдаваемому этапу.;
успешного прохождения приёмочных испытаний;
завершена опытная эксплуатация в порядке и продолжительности, установленных
пунктом 18.6 настоящего ТЗ, опытная эксплуатация всей Экосистемы применяется к
этапу 3;
выполнения миграции и сверки данных;
выполнения обязательных требований по безопасности, доступности,
производительности, резервному копированию и восстановлению.
85

подготовлены, письменно утверждены Заказчиком, размещены и проверены
пользовательские юридические документы и юридически значимые интерфейсные
тексты, предусмотренные пунктом 15.7 настоящего ТЗ.
18.4.4 Критерии приемки
Критериями приемки являются соответствие ТЗ, согласованным ЧТЗ и дизайнмакетам; работоспособность на заявленных устройствах и в поддерживаемых браузерах;
отсутствие дефектов Blocker и Critical; выполнение требований доступности,
безопасности, персональных данных, производительности, восстановления и передачи
результатов.
18.4.5 Неполный результат
Отступления от ТЗ, нереализованный обязательный функционал, непереданные
результаты либо незакрытые замечания, препятствующие нормальной эксплуатации,
означают ненадлежащее исполнение. Такой результат не имеет предусмотренной
Контрактом потребительской ценности и не является основанием для приемки и оплаты.
Функции, прямо отнесённые настоящим ТЗ к последующим этапам, не считаются
недоработкой ранее сдаваемого этапа. Основанием для мотивированного отказа в приёмке
являются невыполненные обязательства именно сдаваемого этапа либо дефекты,
препятствующие его штатной эксплуатации.
18.4.6 Назначение экспертизы
Заказчик вправе назначить экспертизу для проверки соответствия результата, и ее
результаты являются основанием для подписания акта.
18.4.7 Приёмка доступности
На этапах 1 и 2 Подрядчик собственными силами проверяет цифровую доступность
публикуемых интерфейсов и пользовательских сценариев на соответствие пункту 13.4
настоящего ТЗ. Результаты проверок и устранения несоответствий входят в комплект
приёмки соответствующего этапа.
В составе этапа 3 Подрядчик за свой счёт обеспечивает независимый аудит
цифровой доступности Экосистемы с привлечением третьего лица, не участвовавшего в
проектировании, разработке и тестировании проверяемых компонентов. Аудит и
подтверждение устранения выявленных несоответствий выполняются к КТ-8.
Аудит должен охватывать официальный сайт, личный кабинет, мобильное
приложение, интернет-магазин в части интерфейсов и интеграционных переходов,
разработанных или изменённых в рамках Контракта, административные интерфейсы,
предназначенные для регулярного использования сотрудниками Заказчика, а также иные
пользовательские интерфейсы, входящие в состав Экосистемы.
Проверка проводится на соответствие требованиям пункта 13.4 настоящего ТЗ и
применимым нормативным документам, указанным в Приложении № 5 к настоящему ТЗ,
и включать автоматизированное и ручное тестирование, проверку с клавиатуры,
программами экранного доступа и иными применимыми ассистивными технологиями,
проверку масштабирования, контрастности, структуры и семантики интерфейсов,
текстовых альтернатив, форм, сообщений об ошибках, мультимедийных материалов,
динамического содержимого и основных пользовательских сценариев.
86
Проверка должна охватывать как минимум регистрацию и авторизацию,
восстановление доступа, поиск и просмотр информации, приобретение билета,
оформление заказа, использование личного кабинета, просмотр билетов и заказов,
управление согласиями и настройками уведомлений, направление обращения, участие в
программе лояльности и игровых активностях, а также иные критичные сценарии,
установленные программой и методикой аудита.
До начала аудита Подрядчик представляет Заказчику сведения о привлекаемом
лице, составе и квалификации специалистов, опыте проведения сопоставимых проверок, а
также программу, методику, перечень проверяемых интерфейсов, сценариев, устройств,
браузеров и ассистивных технологий. Программа и методика аудита подлежат
согласованию с Заказчиком.
При проведении аудита должно быть предусмотрено пользовательское
тестирование с участием людей с инвалидностью либо экспертов, обладающих
подтверждаемым опытом использования соответствующих ассистивных технологий.
Состав участников и формат такого тестирования определяются программой и методикой
аудита.
18.4.8 Итоговый результат, подлежащий приемке
Все контрольные точки являются частями единого результата — цифровой
экосистемы. Сдаче и приемке подлежит полностью функционирующий продукт, согласно
этапам 1 и 2, а также этап 3 – полностью функционирующая Экосистема, введенная в
промышленную эксплуатацию.
Итоговый результат — работающая цифровая экосистема в промышленной
эксплуатации: основной сайт, сайт Фонда, интернет-магазин и мобильное приложение с
единым личным кабинетом, CRM-контуром, программой лояльности, игровыми, AR- и
аудиосценариями, интеграциями, аналитикой и эксплуатационным контуром. Готовность
полного состава Экосистемы подтверждается выполнением условий приёмки этапа 3 и
оформлением документа о приёмке данного этапа. Начало гарантийного срока
определяется пунктом 21.1, начало и продолжительность этапа 4 — пунктом 17.2.1.
Приёмка этапа 3 не заменяет отдельную приёмку результатов стабилизации.
18.5 Комплект приёмки этапов
Этап 1: публичные адреса сайта и магазина; реестр реализованных требований;
протоколы проверки билетных и торговых сценариев, обменов и уведомлений; результаты
нагрузочных испытаний, проверок информационной безопасности и цифровой
доступности силами Подрядчика, проверки восстановления и отката; исходные коды,
конфигурации, инструкции, права и доступы; подтверждение обучения.
Этап 2: публичные адреса полного сайта, сайта Фонда и витрины коллекции;
ссылки на опубликованные приложения; доказательства работы SSO, ЛК, билетов,
заказов, CRM, лояльности, уведомлений и аналитики; результаты испытаний и аудитов
выпуска; проверка переноса и связывания профилей без утраты данных и дублей;
актуальный комплект передаваемых материалов.
Этап 3: полная матрица требований и сценариев С-01—С-27; готовые контентные
продукты по пункту 9.10.12; результаты полных испытаний и независимых аудитов; акт
87
завершения опытной эксплуатации в порядке и продолжительности, установленных
пунктом 18.6; полный комплект передачи по разделам 19 и 20.
Этап 4: отчёт за весь период этапа 4, установленный пунктом 17.2.1 с
показателями доступности и соблюдения сроков реакции и восстановления; реестр
инцидентов и анализ причин критических сбоев; перечень проверенных обновлений;
результаты контрольного восстановления; актуальные регламенты и материалы передачи
сопровождения. На дату приёмки отсутствуют незакрытые дефекты, препятствующие
обязательным сценариям. Для допустимых остаточных замечаний согласованы сроки
устранения.
Каждый этап завершается отдельным документом о приёмке. Повторное
включение стоимости одного результата, лицензии или услуги в разные этапы не
допускается.
18.6 Опытная эксплуатация
Опытная эксплуатация проводится непрерывно на этапе 3 в течение 720 часов в
промышленной среде с выполнением реальных пользовательских, интеграционных и
эксплуатационных сценариев.
Эксплуатация отдельных продуктов после этапов 1 и 2 в указанные 720 часов не
засчитывается. Акт завершения опытной эксплуатации входит в комплект приёмки этапа 3
и сам по себе не является отдельным основанием для оплаты.
В течение опытной эксплуатации обеспечиваются круглосуточный
автоматизированный мониторинг и круглосуточное реагирование ответственных
специалистов Подрядчика на критические инциденты. Реагирование на инциденты иных
приоритетов осуществляется в рабочее время поддержки.
Ведется журнал событий, обращений и дефектов. Критические дефекты
устраняются до завершения опытной эксплуатации. Решение о завершении оформляется
актом.
19. Документация и результаты, передаваемые Заказчику
Группа
Исходный код
Сборка и
развертывание
Архитектура
Данные
API
Дизайн
Тестирование
Состав
Репозитории, история, ветки, теги, зависимости, конфигурации
без секретов.
Инструкции, автоматизированные процессы, артефакты и
контрольные суммы.
Схемы компонентов, интеграций, данных, инфраструктуры и
решений.
Модель данных, справочники, источники достоверных данных
и правила миграции.
Описание методов/событий, схем, ошибок, авторизации, версий
и тестовых примеров.
Редактируемые макеты, библиотека компонентов, токены,
прототипы и правила, включая требования к дизайнисходникам, заданные в Приложении № 3 к настоящему ТЗ.
Утверждённая ПМИ, тестовые сценарии и тестовые данные,
протоколы и отчёты об испытаниях, доказательства
прохождения проверок, реестр дефектов и результаты
повторных проверок.
88
Группа
Безопасность
Эксплуатация
Пользовательская
документация
Учетные записи
Права и лицензии
Передача знаний
Пользовательские
юридические
документы
Состав
Модель угроз в применимом составе, отчеты проверок, SBOM
и реестр уязвимостей.
Технологический паспорт, регламенты релизов, мониторинга,
инцидентов и восстановления.
Руководства редактора, оператора, администратора и
пользователя.
Домены, магазины приложений, аналитика, облачные проекты
и сервисы.
Акты, лицензионные документы, перечень сторонних
компонентов.
Программа, материалы, записи при наличии и протокол
обучения.
Комплект документов, юридически значимые интерфейсные
тексты, реестр размещения, редактируемые исходники,
утверждённые языковые версии, история редакций и
протоколы проверки в соответствии с пунктом 15.7 настоящего
ТЗ.
19.1. Требование к самостоятельной эксплуатации
Документация и исходные материалы должны быть достаточны для сборки,
развертывания, эксплуатации, диагностики и дальнейшего развития квалифицированной
организацией без обязательного участия первоначального Подрядчика. Заказчик вправе
проверить это контрольной сборкой и развертыванием.
19.2. Обучение
Подрядчик проводит не менее одного практического занятия продолжительностью
не менее двух часов для администраторов, контент-редакторов и иных назначенных
Заказчиком сотрудников.
Перед публичными запусками этапов 1 и 2 Подрядчик обучает назначенных
сотрудников работе с вводимыми продуктами. До приёмки этапа 3 проводится итоговое
практическое занятие продолжительностью не менее двух часов. Программы, записи и
инструкции передаются с соответствующим этапом.
В состав обучения входят работа с содержанием, публикация, управление
пользователями и ролями в предусмотренном объёме, обработка типовых ошибок,
просмотр журналов и мониторинга, а также порядок обращения за гарантийным
устранением дефектов.
Подрядчик передаёт программу занятия, инструкцию пользователя и
администратора и материалы обучения. Результат подтверждается протоколом обучения и
самостоятельным выполнением представителями Заказчика согласованных типовых
операций.
20. Интеллектуальные права, лицензии и учетные записи


права на специально созданные результаты передаются Заказчику в объеме,
установленном Контрактом;
Подрядчик гарантирует наличие прав на материалы, которые он предоставляет;
89

сторонние компоненты предварительно раскрываются с указанием версии, лицензии и
ограничений;
 компоненты, создающие обязательные платежи или ограничение передачи другому
подрядчику, требуют письменного согласования;
 домены, сертификаты, репозитории, магазины приложений, аналитические ресурсы и
облачные проекты регистрируются на Заказчика;
 служебные учетные записи и ключи передаются безопасным способом;
 использование пробных и демонстрационных лицензий в промышленной
эксплуатации запрещается;
 передача результата не должна нарушать права авторов, исполнителей, музеев,
архивов, фотографов и иных правообладателей.
Исключительные права на созданные Подрядчиком в рамках Работ концепции,
сценарии, тексты, графику, 2D- и 3D-объекты, аудиозаписи, озвучивание, монтажные
проекты, игровые, AR- и аудиоматериалы передаются Заказчику вместе с
редактируемыми исходными файлами. Подрядчик обеспечивает получение необходимых
прав от авторов, исполнителей и иных привлеченных лиц и передает подтверждающие
документы.
20.1. Реестр внешних компонентов и зависимостей
Подрядчик обязан вести и передать Заказчику реестр всех сторонних программных
компонентов, библиотек, SDK, внешних сервисов и платных зависимостей, согласно
образцу в Приложении № 10.
Включение внешнего компонента допускается при наличии:






законного основания использования;
действующей и совместимой лицензии;
возможности передачи и сопровождения результата;
раскрытой стоимости;
документированного порядка обновления;
отсутствия недопустимой технологической зависимости.
Компоненты с прекращенной поддержкой либо известными критическими
уязвимостями не допускаются в промышленную эксплуатацию без письменного решения
Заказчика и компенсирующих мер.
Для каждого платного сервиса отдельно указываются первоначальные и
регулярные расходы, лимиты тарифа, порядок превышения лимитов и последствия
прекращения оплаты.
21. Гарантийные обязательства и сопровождение
21.1. Гарантия
Гарантийный срок составляет 6 месяцев с даты приёмки этапа 3. С момента
публичного запуска этапа 1 до приёмки этапа 3 Подрядчик устраняет дефекты введённых
продуктов и поддерживает их инфраструктуру в режиме, установленном пунктами 14.4 и
14.5 для периодов вне опытной эксплуатации и стабилизации. Эксплуатация введённых
продуктов в этот период выделяется отдельным комплексом работ в пункте 17.2.2 с
отнесением к цене этапов
90
Гарантия и стабилизация не используются для завершения обязательного объёма,
не выполненного к приёмке.В гарантийный период Подрядчик без дополнительной
оплаты устраняет дефекты программного кода, настроек, интеграций и документации,
вызванные несоответствием результата ТЗ, утвержденной документации либо исходным
материалам Подрядчика. Дефект, заявленный до окончания гарантийного срока, подлежит
устранению и после истечения гарантийного срока.
21.2. Стабилизация
После окончательной приемки и запуска Экосистемы Подрядчик обеспечивает
период стабилизации продолжительностью 90 календарных дней. Стабилизация входит в
цену Контракта.
Стабилизация является самостоятельным этапом 4. Начало и продолжительность
этапа устанавливаются пунктом 17.2.1 настоящего ТЗ. Содержание этапа включает
усиленный мониторинг, дежурство, диагностику, анализ устойчивости, консультации,
профилактическую настройку и сопровождение обновлений в пределах ТЗ.
Исправление собственных гарантийных дефектов остаётся безвозмездной
обязанностью Подрядчика и не может повторно предъявляться к оплате. Новые функции
сверх ТЗ в этап 4 не входят. Приёмка этапа 4 не прекращает оставшиеся гарантийные
обязательства.
Приоритет
Пример
Полная недоступность,
нарушение оплаты/билетов,
Критический
утечка или повреждение
данных
Существенная функция
Высокий
недоступна значимой
группе
Нарушение с обходным
Средний
путем
Низкий
Реакция
Обход
Исправление
15 минут
2 часа
8 часов либо
согласованный
план
1 час
8 часов
2 рабочих дня
4 часа
—
5 рабочих дней
1 рабочий
день
Незначительное нарушение
—
20 рабочих дней
либо
ближайший
согласованный
релиз, но не
позднее
окончания
гарантии
В период стабилизации Подрядчик контролирует работу Экосистемы и интеграций,
анализирует ошибки, участвует в обработке инцидентов, выполняет необходимые
настройки, устраняет дефекты и консультирует Заказчика. Создание новых функций и
развитие сверх требований ТЗ в стабилизацию не входят.
Указанные сроки применяются к дефектам и инцидентам, находящимся в зоне
ответственности Подрядчика. Для инцидентов, вызванных внешними системами,
91
Подрядчик обязан своевременно провести диагностику, предоставить воспроизводимые
доказательства, обеспечить корректную деградацию и участвовать в совместном
восстановлении.
Круглосуточное дежурство и реагирование специалистов Подрядчика на
критические инциденты обеспечиваются в период опытной эксплуатации по пункту 18.6 и
в период стабилизации, установленный настоящим пунктом.
Автоматизированный мониторинг критических сервисов функционирует
круглосуточно начиная с опытной эксплуатации. После завершения стабилизации система
мониторинга, правила оповещения, панели, журналы, инструкции и административные
права передаются Заказчику.
Срок реакции исчисляется с момента автоматического обнаружения или
регистрации инцидента — в зависимости от того, что произошло раньше. Реакция
включает подтверждение получения, назначение ответственного и начало диагностики.
Срок восстановления не может превышать применимый показатель RTO,
установленный пунктом 14.4 настоящего ТЗ. Временное обходное решение не считается
восстановлением, если контрольный сценарий не выполняется, существует риск потери
или повреждения данных либо сохраняется неприемлемый риск безопасности.
Окончательное исправление подтверждается выпуском проверенной версии,
прохождением регрессионной проверки и отсутствием повторного проявления.
Критический инцидент закрывается только после восстановления контрольных
сценариев и подтверждения Заказчиком. Не позднее трёх рабочих дней после
восстановления Подрядчик представляет анализ первопричины и перечень
корректирующих мер.
Под обработкой обращений в период стабилизации понимаются технические
обращения Заказчика и сообщения об инцидентах и дефектах. Обработка обращений
посетителей и выполнение функций операторов клиентского CRM-контура в обязанности
Подрядчика не входят.
После завершения периода стабилизации и до окончания гарантийного срока
установленные таблицей настоящего пункта сроки реакции, предоставления обходного
решения и окончательного исправления продолжают применяться, но исчисляются
исключительно в рабочее время поддержки.
Если обращение зарегистрировано вне рабочего времени поддержки, течение срока
начинается с начала ближайшего рабочего периода. Если срок не истёк к окончанию
рабочего времени, его исчисление продолжается в следующий рабочий период.
Автоматизированный мониторинг продолжает функционировать круглосуточно
начиная с публичного запуска этапа 1. Круглосуточное участие специалистов Подрядчика
после завершения стабилизации требуется только при проведении Подрядчиком
согласованных работ вне рабочего времени — до восстановления штатной работы
Экосистемы.
22. Исключения, допущения и зависимости
В состав Работ не входят действия, прямо не указанные в ТЗ, при этом исключения
не должны противоречить обязательным результатам.
92
Каждая внешняя зависимость должна иметь владельца, срок предоставления,
необходимый результат, альтернативный вариант и порядок фиксации блокировки.
93
Приложение № 1. Матрица сквозных сценариев, приёмочных проверок и доказательств
Матрица устанавливает минимальный объём испытаний и не ограничивает проверки, прямо следующие из функциональных,
интеграционных, эксплуатационных и иных требований ТЗ.
По каждому сценарию фиксируются фактические тестовые данные, среда, версия сборки, дата, исполнитель, ожидаемый и
фактический результат, обнаруженные дефекты и ссылки на доказательства.
Скриншот либо видеозапись интерфейса не являются достаточным доказательством для операций, изменяющих данные или
использующих интеграции. Для таких операций дополнительно представляются идентификатор операции или объекта, Request ID либо иной
идентификатор трассировки, записи журналов, статус очереди или интеграции и подтверждение конечного состояния в авторитетном
источнике.
Код
С-01
С-02
С-03
С-04
С-05
С-06
С-07
С-08
С-09
С-10
С-11
С-12
С-13
С-14
Минимальные обязательные проверки
Актуальные и отсутствующие данные; закрытый филиал; доступный маршрут; мобильное отображение; аналитическое событие.
Фильтры по отдельности и совместно; календарь; сброс; нулевая выдача; ошибка; сохранение параметров; событие поиска.
Успешная покупка; отказ; тайм-аут; неизвестный статус; повторное нажатие; повторный callback; недоступность билетной
системы; возврат и отмена при наличии API.
Активный, использованный, отменённый и возвращённый билет; офлайн-доступ; защита от доступа другого пользователя;
обновление статуса.
Регистрация; вход; истёкший и повторный код; восстановление; изменение контакта; завершение сеанса; защита от перебора.
Изменение данных; фиксация версии согласия; отзыв; прекращение маркетинговой рассылки; сохранение сервисных сообщений;
выгрузка; блокирование или удаление в применимом порядке.
Полнота билетов, заказов, бонусов и обращений; пустое состояние; задержка внешнего источника; отсутствие чужих данных.
Изменение цены и остатка; отклонённая и неопределённая оплата; повторный запрос; доставка; чек; отмена; полный и
частичный возврат; возврат бонусов; недоступность 1С.
Начисление; списание; отмена; истечение; возврат покупки; повтор события; ручная операция; синхронизация каналов.
Получение задания; выполнение; ошибочное условие; повтор; награда; защита от дубля и злоупотребления.
Выдача и отказ в разрешениях; слабая сеть; неподдерживаемое устройство; прерывание; доступная альтернатива.
Запуск; пауза; перемотка; возобновление; потеря сети; сохранение прогресса; текстовая альтернатива.
Создание; маршрутизация; ответ; уведомление; статус; уточнение; закрытие; повторное открытие; недоступность CRM;
повторная доставка.
Email, SMS и push в предусмотренном составе; RU/EN; сервисное и маркетинговое сообщение; отказ канала; повтор; защита от
дубля; переход к объекту; изменение предпочтений.
94
Код
С-15
С-16
С-17
С-18
С-19
С-20
С-21
С-22
С-23
С-24
С-25
С-26
С-27
Минимальные обязательные проверки
Черновик; обязательные поля; предпросмотр; перевод; публикация; отложенная публикация; откат; прекращение прав на
материал; недостаточность прав; журнал.
Недоступность сервиса; нарушение бизнес-сценария; оповещение; Request ID; эскалация; восстановление; закрытие события.
Сборка из репозитория; миграция; тестовая и предпромышленная среды; выпуск; smoke-тест; откат; журнал выпуска.
Восстановление из реальной копии; целостность; RPO; RTO; права доступа; контрольные пользовательские сценарии; протокол.
Новый и существующий профиль; повтор события; сохранность покупки без активации; подтверждение контакта; активация ЛК;
отсутствие маркетингового согласия.
Переходы сайт ↔ ЛК ↔ магазин ↔ приложение; единый ID; язык; целевой объект; предусмотренное состояние; выход и
прекращение сеанса.
Первый запуск; отказ от разрешений; слабая и отсутствующая сеть; фон; офлайн-QR; офлайн-материалы; неподдерживаемая
версия ОС.
Создание перевода; роли; статус; неполный перевод; предпросмотр; публикация; замещение; адреса и метаданные.
Создание, проверка и публикация правила; период действия; ограничения; ручная корректировка; резервирование, выдача и
отмена награды; аудит.
Формула; источник; период; фильтры; возвраты; отмены; дубли; права; обезличивание; экспорт и повторяемость результата.
Назначение и прекращение прав; MFA; запрет самостоятельного повышения прав; отзыв доступа Подрядчика; неизменность и
доступность журналов.
Страницы, навигация и материалы сайта Фонда; мобильная версия; старые URL и перенаправления; публикация через CMS;
аналитика и доступность.
Поиск музейного объекта; источник и актуальность; устойчивый ID; разрешённая цифровая копия; ограничения прав;
недоступность КАМИС или каталога.
95
Приложение № 2. Матрица ответственности по данным
Данные/сущность
Сведения о музейных
предметах
События и сеансы
Авторитетный источник
Музейная учетная/научная
система либо утвержденный
источник
CMS/билетная система по
утвержденной модели
Билеты
Билетная система
Товары и остатки
1С/учетная система
Заказы
Интернет-магазин и 1С в
разделенных ролях
Профиль пользователя
Единый пользовательский контур
Бонусный баланс
Сервис лояльности
Обращения
Клиентский CRM-контур
Аналитические события
Экосистемный
идентификатор
пользователя
Контактные данные
Единый аналитический контур
Сервис единой идентификации
Согласие и версия
согласия
Коммуникационные
предпочтения
Платежная операция
Единый профиль либо CRM в
установленной архитектурой
роли
Единый контур управления
согласиями
Единый профиль/CRM в
разделенных ролях
Платежный провайдер — по
факту платежа; Экосистема — по
Потребители
Сайт, приложение,
поисковый индекс
Правило
ЛК, магазин, приложение,
CRM, аналитика
ЛК, магазин, приложение,
CRM, аналитика
Магазин, приложение,
лояльность
Магазин, ЛК, приложение
Правила синхронизации определяются
архитектурой
Экосистема хранит необходимые
представления и статусы
Экосистема публикует копию и ссылку на
источник
Магазин отображает полученные данные
Источник статуса фиксируется в
интеграции
Все системы,
использующие
CRM получает согласованный набор
соответствующее основание
Магазин, ЛК, приложение
Иные системы передают события, но не
пересчитывают баланс
ЛК
Сайт и приложение отображают доступный
статус
CRM, аналитика
Схема событий версионируется
ЛК, магазин, приложение,
Иные системы сохраняют идентификатор,
CRM, аналитика
но не создают собственную
конкурирующую идентичность
ЛК, магазин, уведомления
Направление синхронизации и приоритет
изменения фиксируются интеграционным
контрактом
Все системы,
Отзыв распространяется на потребителей в
использующие
установленный срок
соответствующее основание
Email, SMS, push,
Сервисные и маркетинговые настройки не
маркетинговые системы
объединяются
Магазин, 1С, CRM,
Экосистема не изменяет результат
аналитика
платежной операции самостоятельно
96
Данные/сущность
Потребители
Правило
Кассовый чек
Авторитетный источник
связи с заказом
ККТ/ОФД
Магазин, 1С, ЛК
Контент страницы
CMS
Сайт, приложение,
поисковый индекс
Медиафайл и права на
него
CMS/DAM либо иной
утвержденный реестр
Сайт, приложение, каталог,
AR
Промокод магазина
Магазин, CRM, аналитика
Бонусная операция
Интернет-магазин либо сервис
лояльности согласно типу
промокода
Сервис лояльности
Хранятся идентификатор, статус и
ссылка/представление чека
Изменение выполняется в CMS;
производные копии обновляются
управляемо
Вместе с файлом хранятся
правообладатель, источник, ограничения и
срок использования
Для каждого типа определяется
единственный механизм проверки
Награда или подарок
Сервис лояльности
Игровой прогресс
Игровой сервис
Аналитический
показатель
Аналитический контур
ЛК, магазин, приложение,
CRM
ЛК, приложение,
магазин/оператор выдачи
Приложение, лояльность,
аналитика
BI и отчеты
97
Потребители передают события, но не
пересчитывают баланс
Резервирование, выдача и отмена имеют
отдельные статусы
Повтор события не создает повторное
прохождение или награду
Формула, источник и владелец
фиксируются в паспорте показателя
Приложение № 3. Требования к дизайн-исходникам








экраны собраны из переиспользуемых мастер-компонентов;
цвета, шрифты, отступы, размеры и состояния заданы токенами/переменными;
используются осмысленные названия слоев и компонентов;
предоставлены состояния загрузки, ошибки, пустого результата, длинного текста и недоступности внешнего сервиса;
ключевые экраны имеют настольный и мобильный варианты; планшетный — при отличающемся поведении;
макеты содержат правила поведения между контрольными ширинами;
готовые макеты отделены от черновиков и имеют статус готовности к разработке;
передаются редактируемые исходники и краткое руководство по дизайн-системе.
98
Приложение № 4. Состав отчетности по контрольной точке
Документ
Отчет о выполнении
контрольной точки
Реестр требований
Реестр дефектов
Протокол испытаний
Реестр решений
Реестр переданных
материалов
Содержание
Работы, результаты, отклонения, риски и ссылки на материалы.
Статус реализации и подтверждение проверки.
Класс, статус, версия, решение и срок.
Среда, данные, шаги, фактический результат и вывод.
Архитектурные и продуктовые решения периода.
Наименование, версия, расположение, контрольная сумма при
необходимости.
99
Приложение № 5. Перечень нормативных правовых и нормативных технических актов
1. Федеральный закон от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
2. Федеральный закон от 27 июля 2006 г. № 152-ФЗ «О персональных данных».
3. Постановление Правительства Российской Федерации от 1 ноября 2012 г. № 1119 «Об утверждении требований к защите персональных
данных при их обработке в информационных системах персональных данных».
4. ГОСТ 28195-89. Межгосударственный стандарт. «Оценка качества программных средств. Общие положения» (утв. постановлением
Госстандарта СССР от 28 июля 1989 г. № 2507).
5. ГОСТ Р 50739-95. Государственный стандарт Российской Федерации. «Средства вычислительной техники. Защита от
несанкционированного доступа к информации. Общие технические требования» (принят и введен в действие постановлением Госстандарта
РФ от 9 февраля 1995 г. № 49).
6. Приказ ФСТЭК России от 18 февраля 2013 г. № 21 «Об утверждении Состава и содержания организационных и технических мер по
обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».
7. Приказ ФСБ России от 10 июля 2014 г. № 378 «Об утверждении Состава и содержания организационных и технических мер по
обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием
средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации
требований к защите персональных данных для каждого из уровней защищенности».
8. ГОСТ Р 2.105-2019. Национальный стандарт Российской Федерации. «Единая система конструкторской документации. Общие
требования к текстовым документам» (утв. и введен в действие приказом Росстандарта от 29 апреля 2019 г. № 175-ст).
9. Приказ ФСТЭК России от 29 апреля 2021 г. № 77 «Об утверждении Порядка организации и проведения работ по аттестации объектов
информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну».
10. ГОСТ 34.602-2020. Межгосударственный стандарт. «Информационные технологии. Комплекс стандартов на автоматизированные
системы. Техническое задание на создание автоматизированной системы» (введен в действие приказом Росстандарта от 19 ноября 2021 г. №
1522-ст).
11. ГОСТ 34.201-2020. Межгосударственный стандарт. «Информационные технологии. Комплекс стандартов на автоматизированные
системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» (введен в действие приказом
Росстандарта от 19 ноября 2021 г. № 1521-ст).
12. Приказ ФСТЭК России от 3 апреля 2018 г. № 55 «Об утверждении Положения о системе сертификации средств защиты информации».
13. ГОСТ Р 51583-2014. Национальный стандарт Российской Федерации. «Защита информации. Порядок создания автоматизированных
систем в защищенном исполнении. Общие положения» (утв. и введен в действие приказом Росстандарта от 28 января 2014 г. № 3-ст).
100
14. ГОСТ Р 56939-2024. Национальный стандарт Российской Федерации. «Защита информации. Разработка безопасного программного
обеспечения. Общие требования» (утв. и введен в действие приказом Росстандарта от 24 октября 2024 г. № 1504-ст).
15. ГОСТ Р 51624-2000. «Защита информации. Автоматизированные системы в защищенном исполнении. Общие требования».
16. Методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах»
(утв. ФСТЭК России 12.04.2026 г.)
17. Методические рекомендации по разработке нормативных правовых актов, определяющих угрозы безопасности персональных данных,
актуальные при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении
соответствующих видов деятельности, утвержденные ФСБ России 31 марта 2015 г. № 149/7/2/6-432.
18. Банк данных угроз безопасности информации ФСТЭК России (http://bdu.fstec.ru);
19. Методический документ. Методика оценки угроз безопасности информации (утв. ФСТЭК России 5 февраля 2021 г.);
20. ГОСТ Р 59795-2021. Национальный стандарт Российской Федерации. «Информационные технологии. Комплекс стандартов на
автоматизированные системы. Автоматизированные системы. Требования к содержанию документов» (утв. и введен в действие приказом
Росстандарта от 25 октября 2021 г. № 1297-ст).
21. Постановление Правительства РФ от 16 апреля 2012 г. № 313 «Об утверждении Положения о лицензировании деятельности по
разработке, производству, распространению шифровальных (криптографических) средств, информационных систем и
телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнению работ, оказанию
услуг в области шифрования информации, техническому обслуживанию шифровальных (криптографических) средств, информационных
систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением
случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных
систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд
юридического лица или индивидуального предпринимателя)» (в редакции Постановления Правительства РФ от 28.08.2023 № 1403).
22. Постановление Правительства Российской Федерации от 3 февраля 2012 г. № 79 «О лицензировании деятельности по технической
защите конфиденциальной информации» (в редакции Постановления Правительства РФ от 27.12.2024 N 1931).
23. Постановление Правительства Российской Федерации от 3 марта 2012 г. № 171 «О лицензировании деятельности по разработке и
производству средств защиты конфиденциальной информации» (в редакции Постановления Правительства РФ от 27.12.2024 N 1931).
24. Приказ ФСТЭК России от 11 апреля 2025 г. № 117 «Об утверждении Требований о защите информации, содержащейся в
государственных информационных системах, иных информационных системах государственных органов, государственных унитарных
предприятий, государственных учреждений».
101
25. Приказ ФСБ России от 18 марта 2025 г. № 117 «Об утверждении Требований о защите информации, содержащейся в государственных
информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий,
государственных учреждений, с использованием шифровальных (криптографических) средств».
26. Федеральный закон от 24 ноября 1995 г. № 181-ФЗ «О социальной защите инвалидов в Российской Федерации», в том числе статья 14
«Обеспечение беспрепятственного доступа инвалидов к информации» (в редакции Федерального закона «О внесении изменений в
отдельные законодательные акты Российской Федерации» №573-ФЗ от 29.12.2025).
27. Постановление Правительства Российской Федерации от 7 февраля 2026 г. № 102 «Об утверждении требований к обеспечению для
инвалидов по зрению доступности информации о деятельности государственных органов и органов местного самоуправления,
содержащейся на официальных сайтах государственных органов, органов местного самоуправления и подведомственных им организаций в
информационно-телекоммуникационной сети “Интернет”».
28. ГОСТ Р 52872-2019. Национальный стандарт Российской Федерации. «Интернет-ресурсы и другая информация, представленная в
электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования
доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности».
29. ГОСТ Р 70176-2022. Национальный стандарт Российской Федерации. «Интернет-ресурсы и другая информация, представленная в
электронно-цифровой форме. Файлы формата PDF. Требования доступности для людей с инвалидностью и других лиц с ограничениями
жизнедеятельности».
30. Web Content Accessibility Guidelines (WCAG) 2.2 — рекомендации Консорциума Всемирной паутины (W3C) по обеспечению
доступности веб-контента.
102
Приложение № 6. Функциональная матрица Экосистемы
ID
Ф-01А
Связанн
ые
сценарии
С-01,
С-02,
С-20,
С-22
Этап
Компонент /
возможность
Основной
сайт
Обязательная
реализация
Этап 1 —
русскоязыч
ный состав
по разделу
9и
пунктом
17.2.1,
включая
страницы
всех
филиалов;
этап 2 —
полный
сайт, поиск
и
английская
версия
интерфейса
Все согласованные
разделы, афиша,
филиалы, события,
новости, поиск,
переход к покупке,
RU/ENинтерфейсы и
управление
контентом.
103
Контрольная
точка и
подтверждаем
ый результат
Настраиваемо
сть и развитие
Расширяемая
контентная
модель,
единые ID,
API,
аналитические
события и
добавление
языков.
Зависи
мости и
огранич
ения
Основной
критерий
приемки
Пройдены
сценарии
поиска
информации,
планирования
визита,
переключения
языка и
перехода к
покупке.
Применительн
о к составу
сдаваемого
этапа; поиск и
переключение
языка
проверяются
при приёмке
этапа 2.
ID
Ф-01Б
Ф-02
Ф-03
Связанн
ые
сценарии
С-26
С-15,
С-22,
С-26
С-05,
С-06,
С-19,
С-20,
С-25
Этап
Контрольная
точка и
подтверждаем
ый результат
Основной
критерий
приемки
Обязательная
реализация
Сайт Фонда
Этап 2
Перенос под
управление общей
CMS с
сохранением
действующего
дизайна,
содержания,
адресов и
пользовательского
поведения
Расширяемая
контентная
модель,
единые ID,
API,
аналитические
события и
добавление
языков.
Сценарий С-26
пройден;
визуальная
идентичность и
действующие
функции
сохранены
CMS
Этап 1 —
управление
декабрьски
м
составом;
этап 2 —
полный
состав
Типы контента,
черновики,
публикация,
версии, роли, SEO,
языковые
варианты,
массовые операции
и связанные
материалы.
Расширяемые
модели
контента,
ролей и
процессов без
изменения
типового кода.
Редактор
создает,
проверяет,
публикует и
восстанавливае
т материал.
Этап 2
Регистрация,
безопасный вход,
подтверждение
контактов, единый
ID, согласия и
автоматический
технический
профиль после
покупки.
Единая модель
идентификатор
ов, связанных
профилей и
согласий.
Покупка
привязывается
без дубля;
пользователь
активирует ЛК
безопасным
подтверждение
м.
Единая
идентификац
ия
104
Настраиваемо
сть и развитие
Зависи
мости и
огранич
ения
Компонент /
возможность
ID
Ф-04
Ф-05
Связанн
ые
сценарии
С-04,
С-06,
С-07,
С-13,
С-14,
С-20
С-03,
С-04,
С-19
Этап
Компонент /
возможность
Личный
кабинет
Билетный
контур
Обязательная
реализация
Этап 2
Этап 1 —
действующ
ий виджет;
этап 2 —
интеграция
с единым
ЛК и
историей
билетов.
Профиль, билеты,
заказы, бонусы,
обращения,
избранное,
подписки,
предпочтения и
цифровые
материалы,
связанные детские
профили, привязка
детских билетов,
маршрутов и
достижений.
Переход к покупке,
результат, QRбилет, история
после запуска и
доступные
возвраты/статусы
при наличии API.
105
Контрольная
точка и
подтверждаем
ый результат
Настраиваемо
сть и развитие
Зависи
мости и
огранич
ения
Основной
критерий
приемки
API профиля,
билетов,
заказов и
лояльности.
Данные
пользователя
согласованно
отображаются
во всех
каналах.
События
покупки,
возврата и
посещения;
сверка с
источником.
На этапе 1
проверяется
покупка через
действующее
решение; на
этапе 2 —
привязка
билетов к
единому
профилю,
отображение в
ЛК и миграция
покупок
начиная с
запуска этапа
1.
ID
Связанн
ые
сценарии
Ф-06
С-08,
С-19,
С-20
Ф-07
С-01—
С-07,
С-10—
С-14,
С-20,
С-21.
Этап
Компонент /
возможность
Обязательная
реализация
Контрольная
точка и
подтверждаем
ый результат
Настраиваемо
сть и развитие
Зависи
мости и
огранич
ения
Основной
критерий
приемки
Интернетмагазин
Этап 1 —
редизайн
продукта;
этап 2 —
общие
SSO, ЛК,
CRM и
лояльность
.
Редизайн, единый
вход, каталог,
корзина, заказ,
оплата, ЛК, CRM,
аналитика и
лояльность.
Единые ID
пользователя и
заказа, события
и API.
В изменяемой
Подрядчиком
части
обеспечены
единый вход,
сквозные
переходы,
лояльность,
CRM и
аналитика;
существующие
сценарии
заказа, оплаты,
обмена с 1С и
фискализации
не нарушены
действиями
Подрядчика.
Мобильное
приложение
Этап 2 —
публичный
запуск;
этап 3 —
полный
готовый
контент
Редизайн, ЛК,
билеты, заказы,
лояльность,
уведомления,
маршруты, аудио,
игровые и ARсценарии.
Общий
backend/API,
события и
модель
офлайнданных.
Критические
сценарии
работают на
поддерживаем
ых версиях iOS
и Android.
106
ID
Ф-08
Ф-09
Ф-10
Связанн
ые
сценарии
С-09,
С-10,
С-23
С-10
С-11,
С-21
Этап
Компонент /
возможность
Обязательная
реализация
Контрольная
точка и
подтверждаем
ый результат
Настраиваемо
сть и развитие
Зависи
мости и
огранич
ения
Основной
критерий
приемки
Программа
лояльности
Этап 2 —
основные
механики;
этап 3 —
связь с
готовыми
контентны
ми
продуктам
и
Игровые
механики
Этап 2 —
проверенн
ые
механизмы
; этап 3 —
обязательн
ый объём
готовых
продуктов
Обязательный
объём реализации
— в соответствии с
пунктом 9.10.12
Каталог
событий,
заданий,
наград и точки
расширения.
Условие
проверяется,
результат
фиксируется и
награда
начисляется
один раз.
AR
Этап 2 —
проверенн
ые
механизмы
; этап 3 —
обязательн
ый объём
готовых
продуктов
Обязательный
объём реализации
— в соответствии с
пунктом 9.10.12
Модель
контента, API,
события и
привязка к
объектам.
AR работает на
поддерживаем
ых устройствах
и имеет
доступную
альтернативу.
Единый баланс,
начисления,
списания, история,
уровни,
достижения,
подарки, кампании
и защита от
злоупотреблений.
107
Настраиваемые
правила,
события,
согласия и
антидублирова
ние.
Операция
выполняется
один раз и
видна во всех
каналах.
ID
Ф-11
Ф-12
Ф-13
Ф-14
Связанн
ые
сценарии
С-12,
С-21
С-13,
С-14
С-14
С-02,
С-03,
С-08—
С-14,
С-24
Этап
Компонент /
возможность
Аудиогиды
CRM и
обращения
Уведомления
Аналитика
Обязательная
реализация
Контрольная
точка и
подтверждаем
ый результат
Настраиваемо
сть и развитие
Зависи
мости и
огранич
ения
Основной
критерий
приемки
Этап 2 —
проверенн
ые
механизмы
; этап 3 —
обязательн
ый объём
готовых
продуктов
Обязательный
объём реализации
— в соответствии с
пунктом 9.10.12
Модель
маршрута,
трека, языка и
прогресса.
Материал
воспроизводит
ся, прогресс и
аналитика
фиксируются.
Этап 2
Формы, чат, номер,
маршрутизация,
статус, единый
профиль и история
взаимодействий.
Единые ID,
согласия,
события,
сегментация и
API.
Обращение
создается один
раз и доступно
ответственном
у оператору.
Этап 2,
этап 3
Email, SMS и push
в согласованном
составе, RU/ENинтерфейсные
шаблоны.
Раздельная
модель
сервисных и
маркетинговых
согласий.
Отправка и
результат
доставки
журналируютс
я.
Этап 2,
этап 3
Единый план
событий, воронки,
витрины и
согласованные
управленческие
отчеты.
Единые
идентификатор
ы, каталог
событий и
формулы KPI.
Показатель
воспроизводим
о
рассчитывается
из
задокументиро
ванных
источников.
108
ID
Ф-15
Ф-16
Связанн
ые
сценарии
С-01,
С-02,
С-27
С-16—
С-18,
С-25
Этап
Компонент /
возможность
Музейные
данные
Эксплуатацио
нный контур
Обязательная
реализация
Контрольная
точка и
подтверждаем
ый результат
Настраиваемо
сть и развитие
Зависи
мости и
огранич
ения
Основной
критерий
приемки
Этап 3
Получение и
представление
разрешенных
данных из
КАМИС/электронн
ого каталога.
Устойчивые
идентификатор
ыи
документирова
нные
интерфейсы.
Публичные
данные
соответствуют
авторитетному
источнику.
С этапа 1;
развитие и
передача
— этапы
2–3;
стабилизац
ия — этап
4
Среды, сборка,
мониторинг,
журналы,
резервное
копирование,
RTO/RPO,
регламенты и
передача знаний,
миграция
существующих
развёртываний,
проверка
результата
миграции и
возможность
возврата по
согласованному
плану.
Единые
требования ко
всем
компонентам и
независимость
от
первоначально
го Подрядчика.
Выполнены
контрольные
сборка,
развертывание
и
восстановлени
е.
109
Приложение № 7. Матрица ролей
Роль
Объект
Контент-автор
Материалы CMS
Публикующий
редактор
Материалы CMS
Переводчик
Языковые версии
Оператор
обращений
Обращения и
коммуникации
Маркетолог
Кампании и
сегменты
Аналитик
Оператор
лояльности
Менеджер
лояльности
Администратор
лояльности
Администратор
продукта
Разрешенные операции
Создание, изменение,
предварительный просмотр
Публикация, снятие с
публикации, восстановление
версии
Ограничения
Без публикации и удаления
опубликованного материала
Обязательный аудит
Только утвержденный контент
Публикация, откат, снятие
Создание и изменение перевода
Без изменения оригинала и
самостоятельной публикации
Изменение перевода
Просмотр назначенных
обращений, ответ, изменение
статуса
Без массового экспорта и доступа к
техническим настройкам
Просмотр, ответ, изменение
статуса
Создание и изменение
Только при наличии оснований и
Создание кампаний, сегментов
Запуск кампании и
согласий; без произвольного экспорта
и шаблонов
изменение сегмента
ПДн
Просмотр и экспорт
Экспорт и доступ к
Отчеты и витрины
По умолчанию обезличенные данные
разрешенных отчетов
детализированным данным
Операции
Просмотр истории, обработка Без изменения правил и массового
Просмотр и изменение
лояльности
обращения
начисления
статуса
Публикация правила после
Правила, уровни, Настройка правил, дат,
Любое изменение и
согласования; без удаления истории
награды
ограничений
публикация правила
операций
Запрещена корректировка без
Ручная корректировка с
Значение до/после,
Бонусный счет
комментария и идентификатора
указанием основания
основание, пользователь
основания
Настройки
Справочники, формы, шаблоны, Без доступа к инфраструктуре и
Изменение критичных
продукта
функциональные настройки
секретам
настроек
110
Роль
Объект
Технический
администратор
Среды и
компоненты
Администратор
безопасности
Администратор
доступа
Аудитор
Права и журналы
Пользователи и
роли
Документы и
журналы
Разрешенные операции
Ограничения
Обязательный аудит
Входы, релизы,
Развертывание, диагностика,
Отдельная привилегированная учетная
конфигурации,
восстановление
запись, MFA
восстановление
Аудит прав, просмотр событий
Просмотр и изменение
Без изменения бизнес-данных
безопасности
политик
Создание, блокирование,
Запрет самостоятельного назначения
Все изменения прав
назначение прав
себе расширенных полномочий
Сам факт доступа к
Просмотр журналов и отчетов Только чтение
защищаемым журналам
111
Приложение № 8. Матрица интеграций
Источник
Получатель
Данные
Направление
Механизм
Частота
Сервис
идентификации
Сайт, магазин,
личный кабинет, Авторизация, ID,
Двустороннее
мобильное
профиль, согласия
приложение
API/единый вход
В реальном
времени
CMS
Сайт и
приложение
Страницы,
события,
филиалы,
новости, меню
API/публикация/
индекс
При публикации
Из CMS
Сайт, ЛК,
Билетная система
приложение
Сеансы, результат
покупки, билет, Преимущественно из Виджет/API/
QR, возврат,
билетной системы
webhook
посещение
В реальном
времени/по
расписанию
КАМИС/
электронный
каталог
Разрешенные
Из авторитетного
сведения и
источника
цифровые копии
API/выгрузка/
индекс
По событию либо
расписанию
Товары, цены,
остатки, заказы, Двустороннее
статусы, возвраты
API/
В реальном
регламентированн времени/по
ый обмен
расписанию
Платежный
провайдер
Идентификатор
заказа, сумма,
Двустороннее
результат платежа
Защищенный
API/webhook
В реальном
времени
Интернетмагазин/билетный ККТ/ОФД
контур
Расчет, возврат,
Двустороннее
контакт для чека
API
В реальном
времени
Сайт,
приложение,
поиск
Интернет-магазин 1С
Интернет-магазин
112
Отказ/деградация
Действующий сеанс
сохраняется в
безопасном объеме;
новый вход
временно
недоступен
Отображается
последняя успешно
опубликованная
версия
Пользователю
сообщается о
недоступности;
повтор покупки без
подтверждения не
инициируется
Используется
последняя успешная
версия с указанием
актуальности
Заказ не теряется;
формируется
очередь повторной
передачи
Повторная проверка
статуса; исключение
повторного списания
Фиксируется ошибка
фискализации и
выполняется повтор
по регламенту
Источник
Получатель
Bitrix24 —
Сайт, магазин, ЛК,
клиентский
приложение
CRM-контур
Данные
Направление
Механизм
Профиль,
обращения, чат,
В CRM; для
согласия,
API/webhook/
обращений и статусов
согласованные
виджет
— двустороннее
события и
доступный статус
Частота
В реальном
времени/пакетно
Отказ/деградация
События ставятся в
очередь; обращение
не создаётся
повторно; ПДн не
включаются в
технические
журналы
Система
мониторинга и
Обезличенный
Персональные и
Корпоративный
технический
инцидент, номер, Двустороннее
API/webhook
По событию
клиентские данные
портал
контур управления
статус
не передаются
инцидентами
Покупки,
посещения,
Повтор события не
Сайт, магазин,
Сервис
задания,
Двустороннее
Событийный API По событию
вызывает повторного
приложение
лояльности
начисления,
начисления
списания
Шаблон,
Повторная отправка
Сервис
Сайт, ЛК, CRM
получатель,
Двустороннее
API/очередь
По событию
по правилам; защита
уведомлений
отправка, статус
от дублей
Продуктовые и
Сбой аналитики не
Аналитический
В аналитический
По
Все компоненты
технические
SDK/API/очередь
блокирует основной
контур
контур
событию/пакетно
события
сценарий
Метрики, логи,
Локальная
Мониторинг и трассировки,
В эксплуатационный
Все компоненты
Агенты/API
Постоянно
буферизация в
журналы
события
контур
допустимом объеме
безопасности
Строки интеграций с 1С, платёжным провайдером, ККТ и ОФД описывают обязательные сквозные сценарии и точки взаимодействия.
Ответственность Подрядчика ограничивается разработанными или изменёнными им компонентами, интеграциями и сохранением ранее
существовавшей работоспособности в части, затронутой Работами.
113
Схема интеграционного контура
Схема интеграционного контура
Пользовательские каналы
сайт · магазин · приложение
Единый интеграционный контур
Профиль, CRM
CMS, КАМИС
Билеты, магазин
Аналитика
и лояльность
и медиаданные
1С и платежи
и эксплуатация
Приложение № 9. Минимальный каталог событий аналитики
Код
Событие
Обязательные параметры
page_view
Просмотр страницы URL, тип страницы, язык, источник перехода Без избыточных ПДн
114
Примечание
Код
Событие
Обязательные параметры
Примечание
search_performed
Выполнение поиска Запрос, фильтры, количество результатов
Поисковый запрос проверяется на недопустимые
данные
event_view
Просмотр события
ID события, филиал, дата, тип
ID должен совпадать во всех каналах
ticket_purchase_click Переход к покупке
ID события, сеанс, канал
Не считается успешной покупкой
ticket_purchase_resul
Результат покупки
t
ID заказа/билета, статус, сумма при
допустимости
Источник результата — билетная система
registration_result
Результат
регистрации
Канал, результат, тип ошибки
Пароли и коды не передаются
login_result
Результат входа
Канал, результат, тип ошибки
Без секретов
product_view
Просмотр товара
ID товара, категория, цена
ID соответствует учетной системе
add_to_cart
Добавление в
корзину
ID товара, количество, цена
Повтор события не равен повторному заказу
order_created
Создание заказа
ID заказа, сумма, доставка
До результата платежа
payment_result
Результат оплаты
ID заказа, ID платежа, статус
Без реквизитов карты
loyalty_operation
Операция лояльности ID операции, тип, величина, основание
Уникальный ID для защиты от дублей
task_completed
Выполнение задания ID маршрута, задания, результата
Повтор не создает повторную награду
ar_started
Запуск AR
ID сценария, точка, устройство
Геолокация — только при наличии основания
ar_completed
Завершение AR
ID сценария, результат
Используется для воронки
request_created
Создание обращения ID обращения, тип, канал
Текст обращения не передается в продуктовую
аналитику
notification_result
Результат
уведомления
Разделять сервисное и маркетинговое
Тип, канал, статус
115
Минимальные паспорта KPI
KPI
Формула
Источник
Владелец
Конверсия события в переход к
покупке
Переходы к покупке / уникальные просмотры
события
Сайт/приложение
Владелец публичного продукта
Конверсия оформления заказа
Созданные заказы / начатые оформления
Магазин
Владелец магазина
Успешность оплаты
Успешные платежи / все подтвержденные
попытки
PSP/магазин
Владелец коммерческого контура
Успешность авторизации
Успешные входы / валидные попытки входа
Сервис
идентификации
Владелец пользовательского
контура
Активность лояльности
Пользователи с операцией / участники
программы
Сервис лояльности
Владелец программы лояльности
Завершение игрового маршрута
Завершившие / начавшие маршрут
Игровой сервис
Владелец игрового продукта
Доставка уведомлений
Доставленные / принятые к отправке
Сервис уведомлений Владелец коммуникаций
Доля ошибок интеграций
Ошибочные операции / все операции
Мониторинг
Технический владелец
Мониторинг
Эксплуатация
Доступность критических сервисов По формуле §14.2.1
116
Приложение № 10. Форма реестра внешних компонентов и зависимостей
Компонент/сервис
[___]
Назначени
Окончание
Версия Лицензия Стоимость Владелец аккаунта Размещение данных
е
поддержки
Альтернатива
Заказчик/
Подрядчик
[___]
[___]
[___]
[___]
[___]
117
РФ/не обрабатывает
данные
[___]
Приложение № 11. Матрица миграции и первичного наполнения
Объем фиксируется по результатам инвентаризации на согласованную дату отсечения. Если численное значение не задано, обязательным
является весь актуальный опубликованный объем соответствующего источника, отвечающий условиям строки. Молчаливая потеря данных
не допускается.
ID
МИГ01
МИГ
-02
МИГ
-03
МИГ04
Источник
Объект и объем
Правило миграции / наполнения
Критерий приемки
Ответственность
Действующий
сайт
Опубликованные
страницы, новости,
события и справочные
материалы
Инвентаризация; перенос в
новую модель; очистка
технического мусора
Все актуальные материалы
учтены; выборочная сверка
100% обязательных полей
Заказчик:
контент/решения;
Подрядчик:
перенос
Действующий
сайт
URL и поисковый
трафик
Карта старый URL → новый
URL; 301 для замененных
адресов; перечень исключений
Нет массовых 404;
критические URL
перенаправлены; sitemap и
canonical корректны
Подрядчик
Медиаархив
сайта
Изображения,
документы,
Перенос только материалов с
аудио/видео,
подтвержденным основанием;
альтернативные тексты дедубликация; контроль ссылок
и права
Файлы открываются, связи
сохранены, права/источник
доступны
Заказчик: права;
Подрядчик:
технический
перенос
Интернетмагазин
Все активные
категории и товары на
дату отсечения
Количество и ключевые
поля сверены; товары без
цены/остатка обработаны
по правилу
Совместно с
владельцем
1С/магазина
Категории, SKU, свойства,
изображения, описания;
цены/остатки — из 1С
118
ID
МИГ
-05
Источник
Интернетмагазин
Объект и объем
История заказов
Правило миграции / наполнения
Сохраняется действующая
история заказов интернетмагазина. К завершению этапа 2
выполняются миграция и
отображение в едином личном
кабинете заказов, оформленных
начиная с публичного запуска
этапа 1, с переносом изменений
за переходный период и
итоговой сверкой.
Отображение в едином личном
кабинете более ранних заказов
определяется согласованными
возможностями API или
экспорта и правовыми
основаниями. Это не допускает
удаления существующей
истории из исходной системы.
119
Критерий приемки
Ответственность
Новые заказы
отображаются без
расхождений; решение по
старой истории
задокументировано
Подрядчик +
владелец магазина
ID
Источник
Объект и объем
Правило миграции / наполнения
Критерий приемки
Ответственность
Активные билеты и
Билетная система
QR; история билетов
Отображение активных билетов
и QR является обязательным.
Способ реализации определяется
возможностями билетной
системы: API, виджет,
Статусы и QR сверены с
защищённая ссылка,
источником; повтор
согласованная выгрузка либо
события не создает дубль
иной документированный
механизм. Отсутствие
отдельного метода API само по
себе не исключает обязательный
сценарий С-04.
Подрядчик +
владелец
билетной системы
МИГ
-07
Пользовательские
Профили и контакты
учетные записи
Перенос только при
подтвержденном основании;
пароли в открытом виде не
переносятся; предпочтительно
безопасное переподтверждение
Нет дублей и раскрытия
секретов; пользователь
понимает порядок входа
Заказчик
утверждает
основание
МИГ
-08
КАМИС /
электронный
каталог
Мастер-копия не переносится;
создается разрешенная
публикационная копия/индекс и
связи по устойчивым ID
Данные соответствуют
авторитетному источнику;
актуальность и источник
указаны
Владелец
КАМИС +
Подрядчик
МИГ
-9
Открытые обращения и
согласованный
CRM / обращения
профиль
взаимодействий
Перенос или интеграционное
отображение по утвержденной
схеме; тексты не попадают в
продуктовую аналитику
Открытые обращения не
потеряны; права доступа
соблюдены
Заказчик:
перечень;
Подрядчик:
реализация
МИГ
-06
Музейные данные и
цифровые копии
120
ID
Источник
Объект и объем
Правило миграции / наполнения
МИГ
-10
Настройки и
справочники
Филиалы, здания, типы
Единые коды, владельцы и
событий, льготы,
правила обновления
шаблоны
МИГ
-11
Архив исходных
данных
Экспорты, журналы и
протоколы миграции
Неизменяемая копия исходного
набора; контрольные суммы;
защищенное хранение
Обязательные протоколы миграции







акт инвентаризации источников с количеством объектов и объемом файлов;
таблица сопоставления полей, справочников и идентификаторов;
отчет пробной миграции с перечнем ошибок и принятых решений;
протокол итоговой загрузки, контрольных сумм и количественной сверки;
протокол выборочной содержательной сверки Заказчиком;
реестр исключений с причиной, владельцем решения и способом доступа к архиву;
план отката и подтверждение сохранности исходного набора.
121
Критерий приемки
Ответственность
Нет конфликтующих
значений; справочники
версионируются
Заказчик
утверждает;
Подрядчик
загружает
Возможна сверка и откат;
доступ ограничен
Подрядчик
передает
Заказчику
Приложение № 12. Матрица уведомлений
Поле
Что фиксируется
Приоритет
Критический, высокий, средний, низкий
Событие
Условия присвоения приоритета
Первичный канал
Система мониторинга/проектная система
Резервный канал
Телефон, email, мессенджер
Получатели
Основной и резервный ответственные
Срок первичного
уведомления
В соответствии с пунктом 15.2 настоящего ТЗ
Срок реакции
В соответствии с пунктом 21.2 настоящего ТЗ
Уровни эскалации
Конкретные интервалы устанавливаются матрицей уведомлений и не могут ухудшать сроки,
предусмотренные пунктами 15.2 и 21.2
Периодические статусы
Частота информирования во время инцидента
Условия закрытия
Восстановление, проверка, подтверждение
Отчёт о причинах
Срок и ответственный
122

=== ФАЙЛ: Ответ на запрос 0373100047526000034-ЗД91454 | docs/0373100047526000034/Ответ на запрос 0373100047526000034-ЗД91454.pdf
Добрый день, уважаемый участник!
№ Вопрос
Ответ
1
У кого на дату закупки
находятся исключительные
права на существующие
цифровые продукты:
основной сайт музея, сайт
Фонда, интернет-магазин,
мобильные приложения,
личный кабинет?
2
Предоставляем имеющийся исходный код существующих
продуктов. Репозитории с историей изменений, инструкции
сборки, схемы баз данных и конфигурации развёртывания
как отдельный комплект не предоставляются. Исходные
Какими неисключительными платформы указаны в п. 3.2 ТЗ: интернет-магазин — 1Справами и какими исходными Битрикс, мобильное приложение — Flutter, электронный
кодами обладает Заказчик по каталог — КАМИС «Коллекция онлайн».
каждому из этих продуктов?
По интернет-магазину у Заказчика имеется лицензия на
Просим указать состав ПО,
программный продукт «1С-Битрикс24: Интернет-магазин +
включая CMS, модули
CRM». Указанная лицензия дает неисключительные права на
магазина и сторонние
использование соответствующего функционала CMS,
компоненты (OSS и ПО по
модулей интернет-магазина и CRM в объеме,
неисключительным
предусмотренном лицензией.
лицензиям).
Фактический состав компонентов, модулей, редакций и
лицензий Подрядчик устанавливает при обследовании.
Необходимую документацию Подрядчик подготавливает в
составе предусмотренных ТЗ работ.
3
Имеются ли лицензии
(сублицензии) третьих лиц на
компоненты продуктов,
ограничивающие
модификацию, встраивание
новых модулей или передачу
результата другому
подрядчику (пункт 20 ТЗ)?
Специальная проверка условий действующих сторонних
лицензий не проводилась; подтверждённые сведения об
ограничениях отсутствуют. Проверка лицензий и фиксация
ограничений входят в обследование по п. 3.2 ТЗ. Целевая
лицензионная схема должна обеспечивать законное
использование, модификацию и дальнейшее сопровождение
результата Музеем либо привлечёнными им лицами с
соблюдением раздела 20 ТЗ.
4
Кто является текущим
разработчиком
(сопровождающим) сайта,
магазина и мобильных
приложений? Предусмотрено
ли его участие в передаче дел
Исполнителю?
Действующий подрядчик по разработке и сопровождению
указанных продуктов отсутствует. Передачу имеющегося
исходного кода и исходных сведений организует Музей.
Гарантированное участие прежних разработчиков в передаче
дел не предусматривается.
Исключительные права на существующие основной и
дополнительный сайты, интернет-магазин и мобильное
приложение принадлежат Музею. Единый личный кабинет
создаётся в рамках настоящего контракта с интеграцией
существующих пользовательских сервисов. Права на
стороннее программное обеспечение определяются
условиями соответствующих лицензий.
1
№ Вопрос
Ответ
5
Требуется ли передача
исключительных прав на
создаваемый контент
(сценарии, тексты, графику,
2D/3D-объекты, аудиозаписи)
или достаточно
неисключительной лицензии?
В каком объёме Заказчик
передаёт права на
собственные материалы —
изображения экспонатов,
архивные материалы, тексты
(раздел 20 ТЗ)?
6
В какой срок (в рабочих днях)
после заключения контракта
Передаём имеющийся исходный код. Полный комплект
Заказчик передаст исходный
репозиториев с историей изменений и технической
код, репозитории и
документации не предоставляется.
техническую документацию
по существующим
продуктам?
7
Будут ли предоставлены
тестовые и промышленные
среды существующих
продуктов, доступы к API,
схемам баз данных и
профилям развёртывания? В
какой срок?
На специально созданные в рамках работ концепции,
сценарии, тексты, графику, 2D/3D-объекты, аудиозаписи,
озвучивание и другие контентные результаты требуется
передача исключительных прав Музею вместе с
редактируемыми исходниками в соответствии с разделом 20
ТЗ. Подрядчик обеспечивает получение необходимых прав от
авторов и исполнителей. Исходные музейные материалы
отбираем совместно с Подрядчиком при разработке
сценариев и предоставляем для исполнения контракта в
пределах имеющихся прав. Предоставление этих материалов
не означает отчуждения исключительных прав на них.
Готовые технологические среды существующих продуктов и
доступы к ним не предоставляются. Целевые среды создаёт и
настраивает Подрядчик по п. 12.2.1 ТЗ. Потребность в
доступах к внешним системам и исходным данным
определяется при обследовании. Музей обеспечивает
предоставление имеющихся у него необходимых
полномочий и доступов.
Доступы, имеющиеся у Музея на момент заключения
контракта, могут быть предоставлены Подрядчику в течение
5 (пяти) рабочих дней с даты заключения контракта.
Доступы, запрашиваемые Подрядчиком в ходе исполнения
контракта, предоставляются Музеем в течение 3 (трех)
рабочих дней с даты получения соответствующего запроса
при условии наличия таких доступов у Музея.
Предоставление указанных доступов осуществляется в
объеме, необходимом для выполнения работ, и не изменяет
установленный контрактом порядок создания целевых сред
Подрядчиком.
2
№ Вопрос
Ответ
Подрядчик в ходе обследования определяет необходимые
интерфейсы, документацию, доступы и участие поставщиков
билетной системы, 1С, КАМИС, Bitrix24, платёжного
провайдера, ККТ и ОФД. Музей обеспечивает
организационное взаимодействие и предоставление
имеющихся у него доступов. Ограничения и внешние
зависимости фиксируются в порядке п. 11.15 ТЗ.
8
В какой срок
предоставляются доступы и
документация по внешним
системам: билетная система,
1С, КАМИС (электронный
каталог), Bitrix24, платёжный
провайдер, ККТ и ОФД
(пункт 11.15 ТЗ)?
9
Используется билетная система HighWay Media. Подрядчик
обследует доступные способы интеграции, состав методов и
данных, наличие документации и тестового контура. Музей
обеспечивает необходимое организационное взаимодействие
Какие методы интеграции
с поставщиком. На этапе 1 сохраняется действующий
доступны у билетной системы
билетный сценарий, на этапе 2 обеспечивается
(виджет, API, webhook, QR),
предусмотренная ТЗ интеграция с единым пользовательским
есть ли тестовый контур и кто
контуром. Отображение активных билетов и QR обязательно;
владелец системы со стороны
способ реализации определяется доступными возможностями
Заказчика?
системы согласно Приложению № 11: API, виджет,
защищённая ссылка, согласованная выгрузка либо иной
документированный механизм. Владелец системы со
стороны заказчика сообщается после заключения контракта.
Имеются ли на дату закупки
утверждённые дизайнмакеты, брендбук, дизайнсистема, структура страниц и
10
тексты для наполнения? Если
нет — в какой срок они
предоставляются и кто их
согласовывает?
Доступы, имеющиеся у Музея на момент заключения
контракта, могут быть предоставлены Подрядчику в течение
5 (пяти) рабочих дней с даты заключения контракта.
Доступы, запрашиваемые Подрядчиком в ходе исполнения
контракта, предоставляются Музеем в течение 3 (трех)
рабочих дней с даты получения соответствующего запроса
при условии наличия таких доступов у Музея.
Предоставление указанных доступов осуществляется в
объеме, необходимом для выполнения работ, и не изменяет
установленный контрактом порядок создания целевых сред
Подрядчиком.
Предоставляем брендбук и имеющийся макет основного
сайта. Макет является основой для доработки и согласования
с Музеем в соответствии с ТЗ. Готовый комплект макетов
остальных продуктов и полная дизайн-система не
предоставляются; их разработка входит в обязанности
Подрядчика. Имеющиеся структура, тексты и другие
материалы передаются в доступном объёме. Дизайн и
промежуточные результаты согласовывает Музей.
3
№ Вопрос
Ответ
Требуется ли миграция
существующих данных
(контент, пользователи,
заказы, история билетов) в
11
новую инфраструктуру в
рамках контракта? Если да —
за какой период и в каком
объёме?
Да, миграция обязательна по п. 12.2.1 и Приложению № 11.
Подрядчик выполняет инвентаризацию, устанавливает
фактические объёмы, доступную глубину истории, способы
выгрузки и технические ограничения. При отсутствии
численного значения переносится весь актуальный
опубликованный объём соответствующего источника,
отвечающий условиям строки матрицы миграции.
Существующая история заказов магазина сохраняется. К
завершению этапа 2 в едином ЛК отображаются заказы
начиная с публичного запуска этапа 1; более ранние — по
согласованным возможностям API/экспорта и правовым
основаниям, без удаления истории из исходной системы.
Активные билеты и QR должны быть доступны. Профили
переносятся при наличии подтверждённого основания. Для
КАМИС создаётся разрешённая публикационная
копия/индекс со связями по устойчивым идентификаторам;
мастер-база не переносится. План и результаты миграции
согласуются с Музеем.
Предоставляет ли Заказчик
облачную инфраструктуру
или её создаёт Исполнитель?
Просим указать требования к
провайдеру и порядок
12 передачи учётной записи,
доменов, DNS, TLSсертификатов и хранилища
секретов на Заказчика до
запуска первого этапа (пункт
12.2.1 ТЗ).
Инфраструктуру подбирает, создаёт и настраивает
Подрядчик у согласованного российского облачного
провайдера с размещением соответствующих данных и
резервных копий в РФ. Облачная организация, проекты,
биллинг, домены, DNS, TLS-сертификаты, репозитории,
мониторинг, хранилище секретов и иные эксплуатационные
ресурсы оформляются на Музей с момента создания.
Подрядчику предоставляются делегированные права.
Административный контроль Музея обеспечивается до
запуска этапа 1.
Состав готовности сред определяется п. 12.2.1: для первого
запуска — промышленная и тестовая среды и необходимые
средства эксплуатации; к этапу 2 — также среда разработки,
предпромышленная среда и полный сетевой контур.
Кто несёт регулярные
расходы на инфраструктуру
после завершения этапа 4? В
13
каком виде требуется расчёт
таких расходов в составе
заявки?
Расходы на инфраструктуру для разработки, испытаний и
промышленной эксплуатации до завершения этапа 4
включаются в цену контракта без повторного учёта. После
завершения этапа 4 регулярные платежи осуществляет
Музей. Подрядчик раскрывает расходы по сервисам, тарифы,
лимиты и последствия прекращения оплаты в документации
по пп. 12.2.1 и 20.1 ТЗ.
Таблица со списком сервисов инфраструктуры с ценой
данных сервисов. Вид таблицы определяется в ЧТЗ.
4
№ Вопрос
Ответ
Допускается ли развитие
существующих продуктов на
их текущем технологическом
14
стеке (as-is) либо требуется
единый согласованный стек
для всей экосистемы?
Единство Экосистемы обеспечивается согласованной
архитектурой, идентификацией, данными, интеграциями,
интерфейсами и эксплуатацией. Требование использовать
один язык программирования или фреймворк для всех
компонентов не установлено. Для соответствующих веб- и
CRM-компонентов предусмотрены совместимые продукты
семейства 1С-Битрикс/Bitrix24, приложение дорабатывается
на Flutter. Сохранение либо контролируемая замена
серверной части приложения определяется аудитом.
Эквивалентные решения рассматриваются в порядке п. 3.3 ТЗ
при соблюдении требований совместимости, миграции,
безопасности, приёмки и стоимости.
Средства защиты и сетевые ресурсы обеспечивает Подрядчик
в составе инфраструктуры по п. 12.2.1 ТЗ. Требуются
Средства защиты от DDoSпротиводействие DDoS на сетевом и транспортном уровнях,
атак и защиты вебзащита веб-приложений, ограничение запросов и
приложений (WAF)
блокирование аномальной активности.
предоставляет Заказчик или
Отказоустойчивый L7-балансировщик либо эквивалент
приобретает Исполнитель?
должен исключать единую точку отказа, обеспечивать
15
Какие требования
маршрутизацию по доменам и URL, проверку доступности
предъявляются к L7компонентов, передачу исходного IP клиента, ограничение
балансировщику и
запросов и соединений, журналирование и применение
статическим публичным IPv4- защитных правил. Выделенные статические публичные IPv4
адресам (пункт 12.2.1 ТЗ)?
обеспечиваются, если внешние системы требуют включения
адресов источника в разрешённые списки; количество
определяется архитектурой. Ресурсы оформляются на Музей.
Требуется ли подключение к
внутренним системам музея
через VPN-туннель? Какой
класс средств
16
криптографической защиты
информации и какие
требования к сетевой
сегментации применяются?
Подключение к внутренним системам Музея осуществляется
через защищённый VPN-туннель с применением сетевой
сегментации согласно п. 12.2.1 ТЗ. Необходимость
применения СКЗИ, требования к их классу и сертификации, а
также состав обязательных мер защиты Подрядчик
определяет и обосновывает по результатам обследования,
модели угроз и анализа применимых нормативных
требований в соответствии с пп. 15.1–15.2 ТЗ. Решения
представляются на утверждение Музею до утверждения
окончательной архитектуры. Необходимость выделенного
канала определяется архитектурой и моделью угроз.
5
№ Вопрос
Ответ
Пункт 1.5 ТЗ упоминает
детализирующие документы
17 (ЧТЗ). Просим предоставить
их перечень, сроки передачи
и порядок утверждения.
ЧТЗ, спецификации, схемы и иные детализирующие
документы разрабатывает Подрядчик в пределах настоящего
ТЗ. Они раскрывают архитектуру, данные, интеграции,
интерфейсы, миграцию, аналитику, испытания, контентные
продукты и другие предусмотренные результаты. Состав
комплекта и последовательность согласования фиксируются
планом работ. Основные проектные результаты и параметры
контентных продуктов согласуются к КТ-2. Документы
утверждает Музей. По п. 1.5 детализация не может
увеличивать или уменьшать объём закупки, исключать
требования, ухудшать показатели либо переносить
обязательный функционал за пределы контракта.
Кто предоставляет контент
для обязательного объёма по
пункту 9.10.12: концепции,
18 сценарии, тексты, графику,
3D-объекты и аудио создаёт
Исполнитель или Заказчик
предоставляет материалы?
Подрядчик производит обязательные пилотные игровые
маршруты, AR-маршруты и аудиогиды под ключ: концепции,
сценарии, тексты, графику, 2D/3D-материалы, аудиозапись,
озвучивание, монтаж, техническую сборку, тестирование и
подготовку к публикации. Исходные музейные материалы
отбираем совместно при разработке сценариев. Музей
проводит научную проверку и согласовывает содержание.
Предоставление исходных материалов не заменяет
обязанности Подрядчика создать готовые контентные
продукты по пп. 9.10 и 9.10.12 ТЗ.
Сохраняется минимум по п. 9.10.12: не менее двух игровых
маршрутов, каждый не менее чем из восьми связанных
заданий; не менее двух AR-маршрутов и двух аудиогидов.
Контент должен демонстрировать все предусмотренные ТЗ
Просим указать предельные
механики. Если минимального объёма недостаточно, объём
параметры пилотного
увеличивается до необходимого для их полного покрытия.
контента: количество точек в Соответствие механик заданиям и точкам маршрутов
каждом AR-маршруте,
фиксируется в проектной и приёмочной документации.
19 продолжительность каждого
Количество AR-точек, состав мультимедиа, число и состав
аудиогида, количество
вопросов викторин, количество остановок и
вопросов в викторине,
продолжительность аудиогидов предлагает Подрядчик на
необходимый объём перевода основе сценариев и согласовывает с Музеем к КТ-2.
на английский язык.
Отдельные численные максимумы ТЗ не установлены.
Массовое производство последующих маршрутов и
аудиогидов в объём работ не входит. Перевод пилотного
музейного контента Подрядчиком не требуется;
интерфейсные элементы должны быть доступны на RU/EN.
6
№ Вопрос
Ответ
На кого оформляются
аккаунты разработчика в
RuStore, App Store и Google
20 Play, кто оплачивает сборы и
подписки и кто отвечает за
прохождение модерации
магазинов приложений?
Приложения должны быть полностью опубликованы в App
Store, Google Play и RuStore к завершению этапа 3. Аккаунты
разработчика не предоставляются. Подрядчик организует их
регистрацию на юридическое лицо Музея, настройку,
подготовку и подписание сборок, подачу материалов,
устранение замечаний, относящихся к результату работ, и
повторную подачу до положительного решения. Музей
предоставляет необходимые сведения и выполняет действия
по подтверждению организации.
Сборы и подписки до завершения этапа 4 оплачивает
Подрядчик в пределах цены контракта; далее — Музей.
Передача сборки на модерацию сама по себе не подтверждает
выполнение требования о публикации.
Просим установить
предельные количественные
показатели объёма при
твёрдой цене: максимальное
число страниц и экранов
дизайн-макетов,
максимальное число
21
интеграционных
взаимодействий,
максимальное число событий
аналитики, число
контрольных точек, к
которым предоставляется
отчётность.
Объём макетов, интеграционных взаимодействий и
аналитических событий определяется полным покрытием
требований и сценариев ТЗ. Он включает обязательные
интерфейсы, состояния и адаптивные варианты, интеграции
по Приложению № 8, события по Приложению № 9 и другим
применимым требованиям. Отдельный произвольный
численный максимум не устанавливается. Детализация не
является основанием для добавления функций вне ТЗ.
Пункт 17.3 предусматривает 13 контрольных точек: КТ-1—
КТ-11, КТ-Д и КТ-М. Результаты и подтверждающие
материалы представляются по соответствующим
контрольным точкам в установленном ТЗ составе.
Пункт 17.2.2 отводит на
комплекс работ этапа 1
период до 120-го
календарного дня с даты
заключения контракта, при
этом КТ-Д и предельная дата
22 этапа 1 установлены на
20.12.2026 (пункты 17.2.1,
17.3). Просим уточнить
планируемую дату
заключения контракта и
порядок соотнесения этих
сроков.
Период до 120-го календарного дня относится к комплексу
разработки общего веб-контура. В п. 17.2.2 отдельно указано,
что состав этапа 1 должен быть выполнен до КТ-Д —
20.12.2026. По п. 17.2.1 относительные сроки контрольных
точек не переносят календарные даты завершения этапов.
Необходимые для раннего запуска результаты
предоставляются в объёме соответствующего выпуска до его
запуска.
Фиксированная дата заключения контракта в ТЗ не
установлена.
7
№ Вопрос
Ответ
Просим указать сроки (в
рабочих днях) рассмотрения
Заказчиком промежуточных
результатов по каждой
23 контрольной точке:
применяется ли к ним общий
пятидневный срок из пункта
17.4 ТЗ или устанавливаются
отдельные сроки.
Да. По п. 17.4 ТЗ промежуточный результат рассматривается
с направлением единого консолидированного перечня
замечаний в течение пяти рабочих дней, если иной срок не
установлен протоколом рабочей встречи. Этот порядок
применяется к промежуточным результатам и не заменяет
установленную контрактом процедуру приёмки
самостоятельных этапов.
Просим подтвердить, что по
критерию оценки
«Квалификация»
учитываются договоры не
только на сопровождение, но
и на создание и развитие
24 информационных систем и
мобильных приложений, и
указать дату окончания срока
подачи заявок, от которой
исчисляется пятилетний
период для последнего акта
сдачи-приёмки.
Пункт 13.4 устанавливает
соответствие WCAG 2.2
уровня AA «в применимой
части». Просим предоставить
25 перечень страниц и экранов,
по которым проверка
доступности проводится в
обязательном порядке, и
порядок её проведения.
Договоры на создание и развитие информационных систем и
мобильных приложений учитываются по критерию оценки
«Квалификация».
Последний акт, составленный при исполнении договора/контракта,
должен быть подписан не ранее чем за 5 лет до даты окончания
срока подачи заявок. Дата окончания подачи заявок указана в
Извещении об осуществлении закупки.
Обязательная область проверок установлена пп. 13.4 и 18.4.7
ТЗ: главная, навигация, афиша, карточка события, переход к
покупке, авторизация, ЛК, QR-билет, история билетов,
обращения, согласия, сообщения об ошибках, мобильная
версия и другие критические сценарии. Аудит охватывает
применимые интерфейсы сайта, ЛК, приложения, магазина и
административные интерфейсы регулярного использования.
Предусмотрены автоматизированные и ручные проверки,
клавиатурная навигация, экранный доступ и другие
применимые ассистивные технологии, проверка
контрастности, масштабирования, семантики, форм и
альтернатив мультимедиа. В независимом аудите участвуют
люди с инвалидностью либо эксперты с подтверждённым
опытом ассистивных технологий. Программу и методику
согласовывает Музей. На этапах 1–2 проверки проводит
Подрядчик собственными силами; независимые аудиты
проводятся только на этапе 3, к КТ-8.
8
№ Вопрос
Пункт 18.6: засчитывается ли
в 720 часов опытной
эксплуатации время
устранения выявленных
26 дефектов и что считается
нарушением её
непрерывности?
Уточнить состав комиссии и
порядок оформления акта.
Ответ
Необходимо накопить 720 зачётных часов опытной
эксплуатации полного состава Экосистемы на этапе 3.
Эксплуатация отдельных продуктов после этапов 1–2 в этот
срок не засчитывается. Исправления, не нарушающие
проверяемые сценарии, не останавливают отсчёт. При сбое,
препятствующем обязательным сценариям или безопасной
эксплуатации, отсчёт приостанавливается; простой не
засчитывается. После восстановления и повторной проверки
затронутых сценариев отсчёт продолжается без обнуления.
Паузы и возобновление фиксируются в журнале и
протоколах. Состав комиссии определяет Музей. Подрядчик
представляет журналы, протоколы и проект акта. Завершение
оформляется актом после накопления 720 зачётных часов,
устранения критических дефектов и выполнения остальных
применимых условий приёмки.
Круглосуточное реагирование специалистов на критические
инциденты обеспечивается в период опытной эксплуатации и
90-дневной стабилизации. После стабилизации до окончания
Действуют ли круглосуточное гарантии сроки из таблицы п. 21.2 продолжают действовать,
дежурство и сроки реакции из но исчисляются исключительно в рабочее время поддержки.
таблицы пункта 21.2 в
Обращение вне рабочего времени запускает отсчёт с начала
течение всего гарантийного
ближайшего рабочего периода.
27
срока (6 месяцев) или только Автоматизированный мониторинг работает круглосуточно с
в период опытной
публичного запуска этапа 1. После стабилизации участие
эксплуатации и
специалистов вне рабочего времени также требуется при
стабилизации?
выполнении Подрядчиком согласованных работ — до
восстановления штатной работы. Гарантия составляет шесть
месяцев с приёмки этапа 3; период стабилизации входит в
гарантийный срок.
9
№ Вопрос
Ответ
К Приложению № 4 к Извещению прилагается рекомендуемая
форма для заполнения данных по контрактам/договорам.
Документы направляются в форме электронных документов
либо электронных образов бумажных документов.
К
оценке
принимаются
договор(ы)/контракт(ы),
представленные в заявке в полном объеме и со всеми
приложениями в форме электронных документов или в форме
электронных образов бумажных документов.
В каком формате
Если документы, подтверждающие квалификацию участника
подтверждается опыт и
исполнение по договорам для закупки, и информация о таких документах содержатся в
открытых и общедоступных государственных реестрах,
оценки заявки: требуется ли
28
размещенных в информационно-телекоммуникационной сети
реестр договоров по
"Интернет", в том числе ведение которых осуществляется в
определённой форме и
единой информационной системе в сфере закупок с
достаточно ли электронных
образов актов сдачи-приёмки? размещением указанных документов на официальном сайте
единой информационной системы в сфере закупок в
информационно-телекоммуникационной сети "Интернет",
вместо направления таких документов участник закупки
вправе
направить
номер
реестровой
записи
из
соответствующего реестра (п.п. ж) п. 28 раздела 5
постановления Правительства РФ от 31.12.2021 № 2604).
10

=== ФАЙЛ: Ответ на запрос | docs/0373100047526000034/Ответ на запрос.pdf
Уважаемый участник!
Брендбук Музея предоставляется Подрядчику после заключения
контракта в составе исходных материалов для выполнения работ,
предусмотренных пунктом 3.4 Технического задания (Приложение № 1 к
Извещению «Описание объекта закупки»).
Брендбук используется для применения фирменного стиля Музея при
разработке и доработке интерфейсов.
